A face detection feature usually starts with a product question, not a code question.

Can we blur faces before publishing images?
Can we check whether a profile photo contains a person?
Can we count people in an uploaded event photo?
Can we reject images where no face is visible?
Can we send suspicious or low-quality uploads to review?

That is the useful angle.

Face detection is not only about drawing a rectangle around someone’s face. In a real app, it becomes part of a bigger image workflow: upload validation, bounding boxes, image quality checks, privacy rules, moderation, review routing, and clean output your frontend can use.

And this is where JavaScript plus LLMAPI can make the workflow easier.

JavaScript handles the app/backend flow. Face detection tools handle the visual detection. LLMAPI can help with image insight, routing, summaries, user-facing messages, and post-processing, especially when your app needs more than raw face coordinates.

In this guide, we’ll walk through how to do face detection with JavaScript using LLMAPI, which tools fit this workflow, how they work, and the best practices that matter before you ship anything involving face images.

What is face detection?

Face detection means finding human faces in an image and returning where they are.

Input:

profile-photo.jpg

Output:

{
  "face_count": 1,
  "faces": [
    {
      "bounding_box": {
        "x": 0.31,
        "y": 0.18,
        "width": 0.28,
        "height": 0.36
      },
      "confidence": 0.99
    }
  ]
}

A face detection API may also return extra details:

Output	What it means
Face count	How many faces were detected
Bounding box	Where each face is located
Confidence score	How sure the detector is
Landmarks	Eyes, nose, mouth, chin points
Pose	Whether the face is turned or tilted
Occlusion	Whether the face is blocked
Quality signals	Blur, brightness, face size, sharpness
Attributes	Provider-specific estimates like glasses, mask, or expression
Review warnings	Reasons the image may need human review

Face detection answers:

Where are the faces?

It does not automatically answer:

Who is this person?

That distinction matters because face identification and biometric recognition are much more sensitive than basic face detection.

Face detection vs face comparison vs face recognition

These terms get mixed together all the time, so let’s separate them early.

Task	What it does	Example
Face detection	Finds faces in an image	“There are 2 faces in this photo.”
Face landmarks	Finds facial points	“Here are eye, nose, and mouth coordinates.”
Face comparison	Compares two faces	“This selfie may match this ID photo.”
Face recognition	Identifies a person from a database	“This person appears to be User 123.”
Liveness detection	Checks if the face is from a live person	“This is likely a real selfie, not a printed photo.”
Face blurring	Uses face boxes to hide faces	“Blur all faces before publishing.”

For this article, we’re focusing on face detection.

That usually means:

image → face locations + metadata → app action

That app action could be blur, crop, reject, approve, count, review, or summarize.

Where LLMAPI fits in face detection

LLMAPI is useful when face detection is part of a broader AI workflow.

A dedicated face detection API is usually best for exact bounding boxes, landmarks, confidence scores, and image-coordinate output. LLMAPI can sit around that detection step and help your app understand, explain, route, and act on the result.

A practical workflow looks like this:

image upload
→ face detection API
→ structured face result
→ LLMAPI insight/routing/message
→ frontend or review queue

For example, the face detector may return:

{
  "face_count": 0,
  "warnings": ["No face detected", "Image appears dark"]
}

LLMAPI can turn that into a better user-facing message:

We couldn’t detect a clear face in this image. Please upload a brighter photo where the face is centered and not covered.

That is the clean division:

Layer	Best job
JavaScript backend	Uploads, validation, API calls, response handling
Face detection API	Face boxes, landmarks, quality signals
LLMAPI	Summaries, routing, explanations, UX copy, workflow decisions
Human review	Final decision for sensitive or unclear cases

This keeps your product flexible without pretending one model should do every job.

Why we can write this guide

We’ve spent around 6 years working with AI APIs, computer vision, image workflows, document automation, JavaScript backends, and LLM-powered post-processing. We also checked current docs for Amazon Rekognition, Azure AI Face, Google Cloud Vision, Eden AI, Face++, Kairos, and LLMAPI-style multimodal workflows.

The practical lesson is simple: face detection works best when the raw detector output is treated as structured evidence.

Your app still needs to decide what happens next.

Amazon Rekognition DetectFaces returns face details such as bounding boxes, confidence, landmarks, pose, quality, emotions, occlusion, and eye direction. Azure AI Face Detect can return face rectangles, landmarks, face IDs, and optional attributes. Google Cloud Vision face detection detects multiple faces and returns face annotations. These tools give you the raw vision data. LLMAPI helps make that data useful inside your app.

What can you build with face detection?

Face detection is useful in many apps.

Use case	How face detection helps
Profile photo validation	Check whether a face exists before accepting upload
Avatar cropping	Crop around the detected face
Face blurring	Hide faces before publishing images
Event photo processing	Count faces or flag group photos
Moderation	Detect people in uploaded images
ID/selfie prep	Check whether exactly one face is visible
Accessibility	Generate safer image descriptions with face count
Photo organization	Group images by number of visible faces
Content review	Route images with many faces to manual review
Quality control	Reject blurry, tiny, dark, or occluded face images

The key is to match the detection output to a real product action.

A face count alone is not that exciting. A face count that drives upload validation, crop suggestions, privacy blurring, or moderation review is useful.

Top tools for face detection workflows

Here are the main tools worth considering for a JavaScript + LLMAPI-style workflow.

Tool	Best for	What it returns
LLMAPI	Image insight, routing, summaries, user messages	Natural-language or structured post-processing
Amazon Rekognition DetectFaces	AWS-native face detection	Bounding boxes, landmarks, pose, quality, attributes
Azure AI Face Detect	Microsoft/Azure apps	Face rectangles, landmarks, face IDs, optional attributes
Google Cloud Vision Face Detection	Google Cloud apps	Face annotations, landmarks, detection confidence
Eden AI Face Detection	Multi-provider access	Unified API across face detection providers
Face++ Detect API	Face boxes, landmarks, attributes	Face rectangles, tokens, landmarks, attributes
Kairos Detect API	Face detection and facial analysis workflows	Faces found, positions, attributes depending on setup
face-api.js	Browser/local experiments	Client-side face boxes and landmarks
MediaPipe Face Detector	On-device/browser/mobile workflows	Fast face detection and landmarks depending on setup

Now let’s break down how these fit.

1. LLMAPI

LLMAPI is the layer you use when your app needs model-powered reasoning or explanation around the face detection result.

For example, your detector returns this:

{
  "face_count": 3,
  "image_quality": "medium",
  "warnings": ["Multiple faces detected"]
}

LLMAPI can help generate:

{
  "decision": "manual_review",
  "user_message": "This upload contains multiple faces. Please upload a photo with only one clearly visible face.",
  "internal_note": "Route to review because this flow expects a single-face profile photo."
}

This is especially useful when your app needs:

1. Human-readable image review notes.
2. Support messages.
3. Moderation summaries.
4. Upload rejection explanations.
5. Workflow routing.
6. Batch reports.
7. Policy-friendly wording.
8. Combining face detection with other image/text signals.

The LLMAPI quick-start docs show an OpenAI-compatible request pattern, which makes it easy to plug into JavaScript backends that already use OpenAI-style SDKs.

A light JavaScript example:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.LLMAPI_API_KEY,
  baseURL: "https://api.llmapi.ai/v1"
});

async function explainFaceDetectionResult(faceResult) {
  const response = await client.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content: "Turn face detection JSON into a short, careful app message. Do not identify people."
      },
      {
        role: "user",
        content: JSON.stringify(faceResult)
      }
    ]
  });

  return response.choices[0].message.content;
}

Use LLMAPI after the detector, not as a replacement for precise face boxes when your app needs coordinates.

2. Amazon Rekognition DetectFaces

Amazon Rekognition DetectFaces is a strong option if your app already runs on AWS.

It can return:

1. Face bounding boxes.
2. Confidence scores.
3. Facial landmarks.
4. Pose.
5. Quality.
6. Emotions.
7. Eye direction.
8. Face occlusion.
9. Mouth open / eyes open.
10. Other provider-specific details.

This is useful for workflows like:

S3 image upload → Lambda/Node backend → Rekognition DetectFaces → store face metadata

Good fits:

1. AWS apps.
2. Face blurring workflows.
3. Upload validation.
4. Event photo processing.
5. Image moderation pipelines.
6. Apps that already use S3 and Lambda.

How it works:

image bytes or S3 object
→ DetectFaces
→ FaceDetails array
→ bounding boxes + attributes

Best practice: use DetectFaces before any stricter face workflow. If no face or multiple faces are detected, your app can ask for a better image before doing comparison, verification, or review.

3. Azure AI Face Detect

Azure AI Face Detect is a good fit for Microsoft-heavy apps.

It can return face rectangles and optional details such as landmarks and attributes depending on configuration and access. Microsoft’s Face API docs also mention face IDs, face rectangles, landmarks, and attributes.

Good fits:

1. Azure apps.
2. Microsoft enterprise workflows.
3. Profile photo validation.
4. Identity-adjacent preprocessing.
5. Apps already using Azure AI services.

How it works:

image
→ Azure Face Detect
→ face rectangles / landmarks / optional attributes
→ backend decision

Important note: Azure Face capabilities may have responsible AI access requirements or limited-access features depending on the capability and region, so check the current Microsoft docs before building a production identity workflow.

4. Google Cloud Vision Face Detection

Google Cloud Vision face detection is useful if your app already uses Google Cloud.

It can detect faces and return face annotations. Google’s Cloud Vision documentation describes Vision API features including image labeling, OCR, landmark detection, and face detection.

Good fits:

1. Google Cloud apps.
2. Image archive processing.
3. Face count detection.
4. Media workflows.
5. Cloud Storage pipelines.
6. Apps that also need OCR, labels, or safe-search signals.

How it works:

image / Cloud Storage URI
→ Vision API FACE_DETECTION
→ face annotations
→ app action

Google Cloud Vision is especially useful when face detection is only one of several image analysis steps.

For example:

detect faces + detect labels + OCR + safe search

That can support richer image moderation or media-processing workflows.

5. Eden AI Face Detection

Eden AI Face Detection APIs are useful when you want a unified API layer across several providers.

Eden AI says it offers a unified API for face detection models, with the ability to switch providers and normalize results. Its AI Gateway docs describe Eden AI as a unified gateway for 500+ AI models from 50+ providers, and its LLMs vs expert models docs separate expert models like face detection from LLM-style tasks.

That split is useful.

Face detection is an expert vision task. LLMAPI-style reasoning is a language/reasoning task. A good app can use both.

Good fits:

1. Teams testing several face detection providers.
2. Apps that want fallback options.
3. Multi-provider AI workflows.
4. Prototypes that may switch providers later.
5. Products that already use Eden AI for other AI features.

How it works:

image
→ Eden AI face detection
→ selected provider result
→ normalized response
→ LLMAPI review/message layer

This is a good route if you do not want to hardwire your app to one cloud provider too early.

6. Face++ Detect API

Face++ Detect API can detect faces and return bounding boxes, face tokens, landmarks, and attributes for detected faces.

Good fits:

1. Face detection demos.
2. Face landmark workflows.
3. Image quality checks.
4. Apps that need face tokens for later provider-specific operations.
5. Teams comparing dedicated face APIs.

How it works:

image file or URL
→ Face++ Detect
→ face_rectangle + face_token + landmarks/attributes

Face++ can be useful when your app needs detailed face landmarks or provider-specific face analysis, but always review privacy, region, compliance, and data handling before sending user face images to any provider.

7. Kairos Detect API

Kairos face API docs describe a detect endpoint where you submit images and Kairos analyzes faces found in the image. Kairos also has broader face recognition and verification workflows.

Good fits:

1. Face detection.
2. Identity-style workflows.
3. Liveness and verification-related products.
4. Apps that want a dedicated face technology provider.

How it works:

image
→ Kairos detect
→ detected faces and related metadata
→ app decision

Kairos can be more relevant if your product may later need face verification, liveness, or identity verification features beyond basic detection.

8. face-api.js

face-api.js is a JavaScript library for face detection and face landmarks in the browser or Node.js.

Good fits:

1. Prototypes.
2. Offline/local demos.
3. Browser-based face detection experiments.
4. Apps that want to avoid sending every image to an external API.
5. Client-side camera previews.

How it works:

browser image/video
→ face-api.js model
→ face boxes / landmarks
→ frontend feedback

This is useful for pre-checks.

For example, your frontend can say:

Move closer. Your face is too small.

before uploading anything to the backend.

For production identity workflows, use client-side detection only as a helper. Do not trust it as your only security layer because browser-side code can be manipulated.

9. MediaPipe Face Detector

Google ML Kit face detection and MediaPipe-style face detection tools are useful for mobile, browser, and on-device workflows.

Good fits:

1. Mobile apps.
2. Browser camera guidance.
3. Real-time face presence checks.
4. Upload quality pre-checks.
5. Privacy-friendly local detection.

How it works:

camera frame
→ on-device detector
→ face box / landmarks / quality hints
→ user guidance

This is great when you want to reduce bad uploads before they reach your backend.

Example UX:

Center your face.
Move closer.
Improve lighting.
Remove sunglasses.

That small frontend guidance can save a lot of failed API calls.

Which tool should you choose?

Here is the practical version.

Need	Best first choice
AWS-native backend	Amazon Rekognition
Azure/Microsoft enterprise app	Azure AI Face
Google Cloud image workflow	Google Cloud Vision
Multi-provider testing	Eden AI
Dedicated face API	Face++ or Kairos
Browser preview	face-api.js or MediaPipe
User-facing explanations	LLMAPI
Review routing and summaries	LLMAPI
Upload quality guidance	MediaPipe / face-api.js + backend detector
Full ID verification	Dedicated identity vendor with liveness and compliance

For most apps, a strong setup is:

frontend pre-check
→ backend face detector
→ LLMAPI explanation/routing
→ human review when needed

That gives you speed, structure, and safer decisions.

What should the API response look like?

Do not return a messy provider blob to your frontend.

Normalize it.

A clean face detection response could look like this:

{
  "status": "success",
  "face_count": 1,
  "decision": "accepted",
  "faces": [
    {
      "id": "face_1",
      "confidence": 0.99,
      "bounding_box": {
        "x": 0.31,
        "y": 0.18,
        "width": 0.28,
        "height": 0.36
      },
      "quality": {
        "brightness": "good",
        "sharpness": "medium"
      },
      "warnings": []
    }
  ],
  "app_message": "One clear face was detected."
}

For a failed profile upload:

{
  "status": "needs_new_image",
  "face_count": 0,
  "decision": "reject_upload",
  "warnings": [
    "No clear face detected",
    "Image appears too dark"
  ],
  "app_message": "Please upload a brighter photo where your face is clearly visible."
}

That is the kind of response your frontend can use without doing detective work.

Suggested decision labels

Use clear labels.

Label	Meaning
accepted	Image passed the face detection rule
reject_upload	Image does not meet requirements
manual_review	Image is unclear or policy-sensitive
needs_new_image	User should upload a clearer photo
multiple_faces_detected	More faces than expected
no_face_detected	No usable face found
low_quality_image	Face exists, but quality is poor
provider_error	Detection API failed

Avoid overly dramatic labels.

For example, do not tell the user:

Verification failed.

when the real issue is:

The photo is too dark for detection.

That difference matters for trust.

Best practices for image quality

Face detection improves a lot when image quality is good.

Ask users for images where:

1. The face is visible.
2. The face is large enough.
3. Lighting is even.
4. The image is not blurry.
5. The person faces the camera.
6. The face is not covered.
7. There is no heavy filter.
8. The image is not overly compressed.
9. The image contains the expected number of faces.
10. The file is a supported format.

Good frontend copy:

Upload a clear photo where the face is visible, centered, and well-lit.

For profile photos:

Use a clear photo with one face. Avoid group photos, sunglasses, masks, and heavy filters.

For event photos:

We’ll detect visible faces so you can blur them before publishing.

The UX should explain the purpose, not just throw an error after upload.

Best practices for privacy

Face images are sensitive.

Even if you are only detecting face boxes, users may still see it as biometric processing. Be careful.

Use these practices:

1. Get clear consent when needed.
2. Explain why face detection is used.
3. Avoid secret background scanning.
4. Store images only when necessary.
5. Delete temporary uploads quickly.
6. Encrypt stored images.
7. Use signed URLs, not public image links.
8. Keep raw images out of logs.
9. Limit admin access.
10. Add audit logs.
11. Let users request deletion when applicable.
12. Review local biometric privacy laws.

A simple privacy-friendly pattern:

process image → return face metadata → delete original upload

If you only need bounding boxes for blur/crop, you may not need to store the original image at all.

Best practices for security

Your JavaScript backend should protect the face detection endpoint.

Add:

1. Authentication.
2. Rate limits.
3. File size limits.
4. MIME type validation.
5. Image dimension checks.
6. Malware scanning for uploads.
7. Abuse monitoring.
8. Request IDs.
9. Error logging without raw image data.
10. Provider timeout handling.
11. Retry limits.
12. Role-based access for review tools.

Keep provider keys on the backend.

Never expose keys for Amazon Rekognition, Azure Face, Google Vision, Eden AI, Face++, Kairos, or LLMAPI in browser code.

The browser can do optional pre-checks. The backend should handle trusted detection and final decisions.

Best practices for UX

Face detection UX should help users fix the upload.

Weak message:

Error.

Better message:

We couldn’t detect a clear face. Try a brighter photo where the face is centered and not covered.

For multiple faces:

This photo includes more than one face. Please upload a photo with only one person.

For low quality:

The face is visible, but the image is too blurry for reliable processing. Please upload a sharper photo.

For review:

This image needs a quick manual review before we can continue.

Keep the tone calm. A face-related error can feel personal, so the wording matters.

Best practices for app logic

Do not make one face detection score carry the whole workflow.

Use rules.

For a profile photo:

0 faces → reject and ask for new image
1 face → accept if quality is good
2+ faces → reject or review
low quality → ask for new image
provider error → retry or show friendly error

For face blurring:

0 faces → publish normally or warn
1+ faces → blur detected boxes
low confidence boxes → manual review if image is sensitive

For event photos:

count faces
→ show “faces detected”
→ let user choose blur/crop/review

For identity-adjacent workflows:

detect one face
→ check quality
→ run liveness if needed
→ compare/verify only after detection passes
→ manual review for edge cases

Face detection is usually the first gate, not the whole identity system.

A simple JavaScript workflow

Here is the light version without turning this article into a code swamp.

POST /detect-faces
→ validate image
→ call provider
→ normalize face boxes
→ apply app rules
→ optionally ask LLMAPI for message/review note
→ return clean JSON

A small Express route might look like this:

app.post("/detect-faces", upload.single("image"), async (req, res) => {
  const image = req.file;

  const validation = await validateImage(image);

  if (!validation.ok) {
    return res.status(400).json({
      status: "needs_new_image",
      warnings: validation.errors
    });
  }

  const rawFaceResult = await detectFacesWithProvider(image.buffer);

  const normalized = normalizeFaceDetection(rawFaceResult);

  const decision = applyFaceRules(normalized, {
    expectedFaceCount: 1
  });

  const appMessage = await createFaceDetectionMessageWithLLMAPI({
    detection: normalized,
    decision
  });

  return res.json({
    ...normalized,
    decision,
    app_message: appMessage
  });
});

That is the shape you want.

Short. Layered. Easy to maintain.

Minimal LLMAPI post-processing example

LLMAPI can take structured face detection JSON and produce a careful message or review note.

import OpenAI from "openai";

const llmapi = new OpenAI({
  apiKey: process.env.LLMAPI_API_KEY,
  baseURL: "https://api.llmapi.ai/v1"
});

async function createFaceDetectionMessageWithLLMAPI({ detection, decision }) {
  const response = await llmapi.chat.completions.create({
    model: "gpt-4o-mini",
    messages: [
      {
        role: "system",
        content: `
You write short, careful app messages about image upload quality.
Do not identify people.
Do not infer age, gender, race, identity, attractiveness, or emotion.
Tell the user what to fix if the upload failed.
        `
      },
      {
        role: "user",
        content: JSON.stringify({
          detection,
          decision
        })
      }
    ],
    temperature: 0.2
  });

  return response.choices[0].message.content;
}

This is a good use of LLMAPI because it improves the workflow without asking the language model to guess exact face coordinates.

Example normalized results

One clear face

{
  "status": "success",
  "face_count": 1,
  "decision": "accepted",
  "faces": [
    {
      "confidence": 0.99,
      "bounding_box": {
        "x": 0.32,
        "y": 0.16,
        "width": 0.27,
        "height": 0.34
      }
    }
  ],
  "app_message": "One clear face was detected."
}

No face detected

{
  "status": "needs_new_image",
  "face_count": 0,
  "decision": "no_face_detected",
  "warnings": [
    "No clear face detected"
  ],
  "app_message": "Please upload a clearer photo where the face is visible and centered."
}

Multiple faces

{
  "status": "needs_new_image",
  "face_count": 3,
  "decision": "multiple_faces_detected",
  "warnings": [
    "This upload contains more than one face"
  ],
  "app_message": "Please upload a photo with only one clearly visible person."
}

Review needed

{
  "status": "manual_review",
  "face_count": 1,
  "decision": "low_quality_image",
  "warnings": [
    "Face detected, but image quality is low",
    "Face appears small in the frame"
  ],
  "app_message": "The face is visible, but the image may be too low quality for automatic processing."
}

This is the kind of output that feels like a product, not just an API dump.

What should LLMAPI avoid here?

LLMAPI should not be used to make sensitive guesses about a person.

Avoid asking it to infer:

1. Identity.
2. Age.
3. Gender.
4. Race or ethnicity.
5. Attractiveness.
6. Health.
7. Emotions from a face.
8. Criminality or trustworthiness.
9. Personality.
10. Whether someone “looks suspicious.”

Keep LLMAPI focused on safe workflow tasks:

1. Explain upload problems.
2. Summarize detection results.
3. Route images to review.
4. Generate reviewer notes.
5. Create batch reports.
6. Help with support messages.
7. Suggest next steps based on structured data.

That keeps the feature useful without getting weird.

Face detection best practices checklist

Use this before shipping.

• Explain why you are detecting faces.
• Get consent when the workflow requires it.
• Keep provider API keys on the backend.
• Validate file type, size, and dimensions.
• Check image quality before sending expensive API calls.
• Normalize provider responses into your own schema.
• Do not expose raw provider output to the frontend.
• Use clear decision labels.
• Give users helpful upload guidance.
• Avoid sensitive facial attribute inference.
• Delete temporary uploads quickly.
• Encrypt stored images if you keep them.
• Redact logs.
• Add request IDs and audit trails.
• Rate-limit upload attempts.
• Add manual review for unclear or sensitive cases.
• Test on real image conditions, not only clean demo images.
• Use LLMAPI for messages, summaries, and routing.
• Use expert face APIs for precise bounding boxes.

This checklist will save you more pain than a giant pile of extra code.

Common mistakes

Mistake	Better approach
Using a vision LLM for exact face coordinates	Use a face detection API for boxes
Returning raw provider JSON	Normalize the response
Giving users vague errors	Explain what to fix
Detecting faces without explaining why	Add consent and purpose copy
Storing every image forever	Use retention rules
Logging image data	Log metadata only
Accepting group photos in single-person flows	Require exactly one face
Ignoring image quality	Check blur, brightness, and face size
Treating detection as identity verification	Add comparison, liveness, review, and compliance
Asking AI to infer sensitive traits	Keep outputs limited and safe

The biggest mistake is thinking face detection ends once the API finds a rectangle.

The useful product work starts after that.

Where this fits in a real app

For a profile photo app:

upload image
→ detect faces
→ require exactly one clear face
→ crop preview
→ save approved image

For a privacy tool:

upload image
→ detect all faces
→ blur face boxes
→ let user preview
→ publish/export

For a moderation workflow:

image upload
→ detect faces
→ combine with other image signals
→ LLMAPI summary
→ review queue if needed

For an identity-adjacent workflow:

selfie upload
→ detect one face
→ quality check
→ liveness / comparison provider
→ review if uncertain

Notice the pattern: face detection is the first structured signal, then the product workflow decides what happens.

The practical takeaway

You can detect faces with JavaScript by building a backend that accepts image uploads, validates them, calls a face detection provider, normalizes the result, and returns useful image insights to your app.

Use tools like Amazon Rekognition DetectFaces, Azure AI Face Detect, Google Cloud Vision Face Detection, Eden AI Face Detection, Face++ Detect, Kairos, face-api.js, or MediaPipe depending on your stack and privacy needs.

Use LLMAPI around the detector when your app needs better messages, review notes, routing, summaries, or workflow automation.

A good setup looks like this:

image
→ JavaScript backend
→ face detection tool
→ normalized face result
→ LLMAPI explanation/routing
→ frontend or review queue

That is how face detection becomes useful: not as a random rectangle in JSON, but as a clean product workflow that helps your app decide what to do with an image.