How to Blur Faces or a License Plate in a Photo (Ask Your AI Assistant)

Why blurring is not the same as hiding

A blur or a mosaic makes a face or a number hard for you to read; it does not reliably make it hard for software to read, and the file around the pixels can still carry the original. Three findings make the case.

Blurred and pixelated faces can be re-identified. In 2016, researchers at Cornell Tech and the University of Texas trained ordinary image-recognition networks on obfuscated photos. On a 40-person test set, faces blurred with the same method YouTube uses were identified correctly 57.75% of the time on the first guess and 85.75% within five guesses, against chance rates of 2.5% and 12.5%. Faces pixelated into 16 x 16 mosaic blocks were identified 96.25% of the time (McPherson, Shokri and Shmatikov, "Defeating Image Obfuscation with Deep Learning", arXiv 2016). The blur was never designed to resist a model that has seen a thousand blurred faces.

Pixelated text can be read back. Depix, a proof-of-concept released in 2020, recovers plaintext from pixelated screenshots by matching the mosaic blocks against renderings of candidate characters; it works on anything pixelated with a plain box filter, which is what most editors use (Depix on Codeberg). A pixelated password, address or plate is a puzzle, not a wall.

The file can keep the original even when the pixels are gone. In March 2023 the "aCropalypse" bug (CVE-2023-21036) showed that Google Pixel's Markup tool had, for five years, saved cropped screenshots without truncating the file, so the end of the original image stayed inside the "cropped" PNG and could be partly restored (SecurityWeek, March 2023). JPEGs have a quieter version of the same problem: the EXIF block usually holds a thumbnail of the picture as it was when the camera saved it, and an editor that blurs the main image and leaves the thumbnail alone has hidden nothing from anyone who opens the file in a metadata viewer.

So "hide this" has three parts: replace the pixels with something that carries no information, throw away the metadata, and make sure no second copy of the picture is riding along inside the file. That is what Mochify's redaction does by default, and it is why the default is a solid fill rather than a blur.

Five words this guide uses

• Redact: replace part of an image so the original content of that part cannot be read back. The verb lawyers use for black bars on documents, applied to pixels.

• Fill: the redaction style that paints the area solid black. The default, and the only one that removes the information rather than smearing it.

• Blur: the cosmetic style. It looks softer, and blurred faces and text can sometimes be partly recovered (section 1), so it is for a look, not for secrecy.

• Box: a rectangle to hide, given as four numbers: left edge, top edge, width and height. Mochify takes them as fractions of the picture from 0 to 1, measured from the top-left corner, never as pixels. 0.5, 0.64, 0.18, 0.06 means "start halfway across and 64% of the way down; cover 18% of the width and 6% of the height". The fractions are measured on the photo as it displays upright, so a phone photo stored sideways still gets the box where you see it.

• Region: a crop, given in the same four-number form. It runs after redaction, so cropping can never bring a hidden area back.

The fastest route: ask your assistant

Connect Mochify's hosted MCP server to an assistant that can see images (Claude Desktop, Cursor, or any client that supports remote MCP servers), attach the photo, and say what you want hidden in plain words. The assistant finds the thing; Mochify hides it. The split matters: the assistant is the only party that ever understands the picture, and all Mochify receives is coordinates. It works on every plan, including Free, because the MCP server is on every plan; the Mochify MCP server page has the redaction prompt and the rest of what the server can do.

The same split is why redaction by box lives on the two MCP surfaces and the REST API, and not in the mochify command-line tool or on the web app: something has to look at the picture and choose the box, and a command line or a text prompt cannot. Faces are the one exception. Mochify's own detector finds them without a box, so you can also ask for them in plain words on any Magic Flow surface, the web app included: "blur every face" or "black out every face". That route shows you no count, so look at the result and count the people yourself; for anyone it missed, or for anything that is not a face, you need the assistant route in this section. If you run the local MCP server (mochify serve) instead of the hosted one, the same instructions apply, with one difference in what comes back: the local server writes the finished file to disk and returns its path, with no download link and no pickup store.

Here is the first real run, exactly as it happened on October 16, 2026, on a 571 x 640 street photo of a parked Audi with a second car's plate just visible at the left edge.

You say: "Hide the license plates in this photo. I'm listing the car for sale."

The assistant does: looks at the image, measures the plate (it sits about 15% in from the left and 54% down, roughly a fifth of the frame wide and 7% tall), notices the sliver of plate on the other car, and calls Mochify's squish tool with two boxes:

redactBoxes: [[0.155, 0.54, 0.205, 0.075], [0, 0.41, 0.045, 0.06]]
type: jpg

Mochify returns: Image processed successfully (image/jpeg, 58.5 KB), a download link, and the line Redacted 2 area(s). Both plates are solid black. The car, the road and the trees are untouched, and the metadata is gone.

The link is short-lived. The hosted MCP server hands back a URL on files.mochify.app that expires in about five minutes; the assistant does not receive the image bytes, only that URL, so your conversation never fills up with a base64 blob. Click it, save the file, done.

If you attached the photo to the chat rather than pointing at a URL: the assistant sees the picture as pixels, not as a file, so it cannot forward your original by itself. It will call create_upload and give you a one-time upload link; drop the same photo on it and the assistant carries on with the returned upload id. The upload is deleted as soon as Mochify reads it, or after fifteen minutes if nothing does.

The one broken case we hit, and its fix. On the first attempt at a small item in a large photo, an assistant judging the box on the whole frame tends to draw it too tight and leave a letter showing at the edge, which is not a hidden plate. The fix is in the tool's own instructions: cover the whole item with a small margin, and for a small item in a big photo, measure on a zoomed-in view. If the first result shows an edge, say "the plate's right edge is still showing, widen the box": the assistant redraws, and the second call costs one more image from your allowance, nothing else.

Why not just ask the chatbot to black it out?

Because the photo a chatbot edits is not the photo you attached. When we measured what five AI chatbots actually receive when you attach a picture, between 80% and 94% of the pixels were gone before any model ran, removed by the upload step along with the camera data, the GPS position, the color profile and the HDR gain map; from a 5712 x 4284 iPhone photo, ChatGPT worked on a 2048 x 1536 copy, Claude on 2576 x 1932 and Perplexity on 1440 x 1080, and Gemini and DeepSeek returned no file at all (the full test is in our guide to what comes back when you ask ChatGPT to compress a photo). We tested compression in that piece, not redaction, so we will not claim what each chatbot does when asked to draw a black box. What we can say is that if it draws one, it draws it on the shrunken copy, and the shrunken copy is what you get back: a redacted listing photo at a fifth of its pixels, or no file at all.

The MCP route separates the two jobs so neither one degrades the other. The assistant looks at the reduced preview, which is all it needs to decide where the plate is, because the box is sent as fractions of the picture rather than pixels: a plate 15% in from the left edge of a 5712-pixel original is 15% in from the left edge of a 2048-pixel preview, and the chat platforms we measured scale proportionally without cropping, so every fraction stays where it was. What the preview does cost is precision on small items, which is why the assistant draws with a margin and you check the result. Mochify, meanwhile, works on the original bytes: the file at the public URL you pasted, or the original you dropped on the one-time upload link. In our first run the 571 x 640 source came back at 571 x 640 with two black boxes and nothing else changed; the group photo came back at 1200 wide only because we asked for that. The assistant's upload pipeline never touches the file Mochify receives, and that holds for any MCP client whose model can see a picture, whatever the model's own upload step does to it.

It is also usually cheaper. The redaction is one tool call and one line of result text in the conversation, not an image generation; the finished file never enters the chat as pixels or as a base64 blob, so a batch of twenty listing photos costs twenty short tool calls, not twenty images' worth of tokens each way.

Faces: let the detector find them, then check its count

For faces you do not need the assistant to draw anything: ask for the faces to be hidden and Mochify's own face detector finds them. It is best-effort, so the useful habit is to read the count it reports and add boxes for anyone it missed.

The second real run used a group photo of fifteen people in front of a statue, at 2496 x 1664 pixels.

You say: "Blur every face in this photo and resize it to 1200 wide."

The assistant calls:

redactFaces: true
redactStyle: blur
width: 1200
type: jpg

Mochify returns: Redacted 12 area(s), 12 of them faces found by the detector (it can miss small or side-on faces).

Twelve of fifteen. The three it missed were the two people at the far left and far right of the standing row, both turned part-way from the camera, and one person standing beside the statue. The statue's own face was, correctly, not treated as a face. That is a typical result for a group photo: strong side profiles and small faces are exactly what the detector's own description says it can miss.

The fix is one more sentence: "It missed the man on the far left and the one on the far right. Cover them too." The assistant keeps redactFaces on, adds two boxes of its own, and the next result reads Redacted 14 area(s), 12 of them faces found by the detector. (In our run the person beside the statue still showed, because we had not asked for him. Count the people yourself before you call it done.)

Two things to take from this. First, the count is in the response for a reason: a 0 is a successful response that hid nobody, so an assistant, or a script, should check it rather than assume. Second, boxes and the detector combine in one call, so there is no need for a separate pass; the detector's faces and your boxes are all hidden together, with the detector's boxes padded for hair, ears and jawline.

If faces are all you need hidden, you do not need an assistant at all. Drop the photo on the Magic Flow page, or use the prompt on any other Magic Flow surface, and ask for every face to be blurred or blacked out. The same detector runs, with the same misses, and that route reports no count, so the check is the picture itself. The assistant route earns its place the moment the detector misses someone: it can see the photo, draw the missing box, and send both in one call.

Crop and redact in one pass

If you also want the photo cropped, say so in the same request; the crop cannot uncover the redaction, because Mochify hides first and crops second.

The third run on the Audi photo asked for a tighter picture of the car as a WebP, with the plate blurred this time:

region: [0.02, 0.35, 0.74, 0.46]
redactBoxes: [[0.155, 0.54, 0.205, 0.075]]
redactStyle: blur
type: webp

Mochify returned a 423 x 294 pixel WebP of 10.3 KB, with Cropped to region x,y,w,h = 11,224,423,294 px of the upright image and Redacted 1 area(s). The plate box was the same four numbers as before, measured on the whole photo, and it still landed exactly on the plate inside the crop.

That last detail is the rule to remember: boxes are always fractions of the full, upright, original image, even when a region is set. The assistant does not have to re-measure anything after deciding on a crop, and a box can never be invalidated by one. The response also tells you the pixel rectangle actually cut, because fractions round and a box that runs past the edge is trimmed to the image.

Width and height, smart crop and rotation all apply to the cropped region, so "crop to the car, hide the plate, make it 1600 wide, convert to WebP" is one call and one image from your allowance.

Fill or blur: which one to ask for

Ask for a fill when the content must stay secret; ask for a blur only when you want the softer look and can live with the chance of recovery. Fill is the default, so if you say nothing you get the safe one.

The decision is about the threat, not the taste. A plate on a car you are selling to a stranger, a delivery label in a product photo, a screen in an office shot: fill. A crowd at a street party where you are being polite rather than protecting anyone: blur is fine. If you are not sure, you were not sure for a reason. Fill.

What happens to the file

A redacted image is processed like every other image Mochify handles, in memory with nothing kept, plus two guarantees that exist only because redaction needs them. Here is the whole path for the hosted MCP route.

1. The assistant sends the image and the coordinates to api.mochify.app. The image does travel to our servers over HTTPS; this is not an on-device operation, and no honest guide should tell you otherwise. It is streamed into the encoder in RAM, never written to disk, and never appears in a log.

2. Face detection, if requested, runs on Mochify's own servers with Mochify's own detector. No third-party vision service sees the photo.

3. The redaction is applied first, then any crop, resize, rotation or format change.

4. The output always has its metadata stripped, even if the request asked to keep it. EXIF can hold a thumbnail of the unredacted picture, so a redacted file is never allowed to carry one. The same rule removes any HDR gain map, because a gain map is a second, lower-resolution image of the scene and could show what the main image hides. If you need HDR or metadata preserved, that is a different job from redaction; do it on a copy you are not redacting.

5. The original is wiped as soon as the encode finishes. On the hosted MCP server, the finished file waits in a pickup store under an unguessable name for about five minutes so the download link works, then it is evicted whether you fetched it or not. On the local MCP server (mochify serve) and the REST API there is no pickup store: the bytes come straight back to your machine and nothing is held at all.

And the part that is easy to miss: the meaning of the redaction never reaches Mochify. The assistant knows it was hiding a plate, a face or a signature. Mochify receives 0.155, 0.54, 0.205, 0.075 and a style. We do not know what was there, and we could not reconstruct it afterwards even if asked, because by then there is nothing to reconstruct from. The same in-memory model is described on our architecture and data handling page, and the processor obligations behind it are in the Data Processing Agreement.

Doing it in bulk: the REST API

If you have your own vision model, or a folder of a thousand listing photos, the same redaction is three query parameters on POST /v1/squish: redact, redactStyle and region. The API was built for exactly the split described above: your code picks the boxes, Mochify receives four numbers.

# Hide a plate (fill) and a second small area, output JPG
curl -X POST "https://api.mochify.app/v1/squish?type=jpg&redact=0.155,0.54,0.205,0.075;0,0.41,0.045,0.06" \
  -H "Authorization: Bearer $MOCHIFY_KEY" \
  -H "Content-Type: image/jpeg" \
  --data-binary @car.jpg -o car-redacted.jpg -D headers.txt

# Hide every face, blur style, and crop to a region, output WebP at 1600 wide
curl -X POST "https://api.mochify.app/v1/squish?type=webp&width=1600&region=0.02,0.35,0.74,0.46&redact=faces;0.155,0.54,0.205,0.075&redactStyle=blur" \
  -H "Authorization: Bearer $MOCHIFY_KEY" \
  -H "Content-Type: image/jpeg" \
  --data-binary @group.jpg -o group-redacted.webp -D headers.txt

Read the response headers, not just the body:

• X-Mochify-Redacted: how many areas were hidden, your boxes plus any faces found.

• X-Mochify-Redacted-Faces: how many faces the detector found. Present only when redact includes faces; a 0 is a successful response that hid no faces, so a pipeline should treat it as "check this one by hand", not as "done".

• X-Mochify-Region: the pixel rectangle actually cut, when region was set.

Rules the API enforces: up to 64 areas per request; every value is a fraction from 0 to 1, and any value above 1 is rejected with a 400 rather than silently treated as a pixel coordinate; a box that runs past an edge is trimmed; redactStyle requires redact. Each request is one image from your plan's allowance, with or without redaction. The full parameter table is on the API documentation page.

For a marketplace seller with a hundred photos and no code, the assistant route in section 3 handles a batch the same way: "hide the plates in all of these", one call per image, one line of results per image to read through.

When you do not need any of this

You do not need redaction when nothing identifying is in the frame, or when the identifying thing is the point of the picture. A product on a white background, a landscape, a screenshot of your own code: compress and convert as usual and move on. The Magic Flow page does that job in one sentence and never touches the pixels you did not mention.

You also do not need Mochify for a single casual photo where a quick smudge on your phone is good enough and nobody is at risk. The route in this guide earns its keep when the hidden thing matters (a plate, a child, an address, a document), when there are many photos, or when the redaction has to be reliable enough to defend later, because then the metadata, the thumbnail and the recoverability of a blur all start to matter, and a fill from a tool that strips everything is the only version you can stand behind.

And it does not cover video. Mochify's video tools run in your browser and do not include redaction; blurring faces in a video is a different job and this guide does not claim to do it.

Mochify workflow: redact a photo from your assistant

Privacy note for this workflow: the photo travels to api.mochify.app for the redaction and the encode, is processed in RAM and wiped immediately, and the finished file sits in the hosted MCP pickup store for about five minutes; the assistant only ever receives the download URL. Face detection runs on Mochify's servers with no third-party service. What the hidden area contained is known to your assistant and to you, never to Mochify.

Ready to try it on a real listing? Connect the server, attach the photo, and ask. If you would rather start with plain compression and conversion, mochify.app does that in the browser with the same in-memory handling.

Cheat sheet

FAQ