Our prompt for making AI images look real used to be 2,300 characters long. It listed every AI tell to remove, every camera detail to add, and rules for colour, shadows and lens optics. It produced faces covered in freckles and skin so drained it looked like a corpse. The version in production today is one sentence.
The lesson generalises to any image-editing prompt: a modern image model already knows what a phone photo looks like, so naming a familiar camera does the work of a page of instructions, and every extra clause is something the model can over-apply.
sparkpix.ai's AI Image Humanizer is a web tool that re-renders an AI-generated image so it reads like a real phone-camera photo, keeping pose and framing. Disclosure: I build sparkpix.ai. This post was drafted with AI assistance for structure and wording; the prompt text, comments and code are from the sparkpix codebase (Next.js App Router on Vercel, calling GPT Image 2 through apimodels.app, September 2026).
Long prompts fail by arguing with themselves
Every clause in the long prompt was added to fix a problem the previous clause created. "Add natural skin texture" produced freckles; "don't add freckles" produced flat skin; "keep healthy colour" fought "remove the saturated AI grade". The model obeyed every clause a little too hard, and the clauses pulled against each other.
What replaced it, tested directly against GPT Image 2 and preferred by eye on 2026-07-30:
export const DE_AI_PROMPT =
'Remove the AI-generated look from this image so it looks natural — for a ' +
'photographic image, like it was taken with an iPhone 12 camera. Keep the ' +
'original art style: an illustration or anime image must stay an ' +
'illustration, not become a photograph.'
"Like it was taken with an iPhone 12 camera" carries the sensor noise, the colour science, the skin rendering and the slightly imperfect light, all at once, because the model has seen millions of those photos. There is no clause left to over-apply.
One word can change the subject instead of the camera
We tried "selfie" in that sentence, and it re-posed people. "Selfie" does not only describe a camera; it describes a photo genre: arm raised, head tilted, shot close and from above. The model read it as an instruction about the person and changed the pose the user had already chosen.
The rule we took from it: name the device, never the genre. "iPhone 12 camera" is about the lens. "Selfie", "portrait shot", "street photo" are about the picture, and the model will happily give you a new picture.
Scope a style instruction, don't negate it
The unscoped sentence, "make it look like an iPhone photo", is also an instruction to convert the medium, and anime uploads started coming back as photographs. The model was doing exactly what it was told.
The tempting fix is to append "do not change the art style". That recreates the original failure: two clauses arguing. Instead, the camera reference is scoped to photographic input ("for a photographic image, like it was taken with…"), and the second sentence adds a constraint rather than a contradiction.
Honest status: the scoped version has not been through the same side-by-side test as the one-sentence version. It is in production because it fixed the anime-to-photo reports, not because it was benchmarked.
Keep the prompt in exactly one place
The first time we shortened the prompt, nothing changed for real users. The wording lived in three places: two tool defaults on the server, and a pre-filled textarea on each landing page. The landing-page copy is what actually reached the model, because the editor sends its textarea as prompt and the server only falls back to its default when prompt is empty. We had edited the fallback.
Now there is one exported constant, imported by both the tool config and the pages, and the old long prompt is not kept as a "fallback", because an unused second copy is how the drift started. It is in git history if anyone needs it.
Failures must refund exactly once
A humanizer call can fail after credits are taken: the model's safety filter refuses the image, or the upstream API errors. The refund has to happen once, even though a failure can be observed by several code paths (the background job, a client poll, a cleanup cron). The pattern is to let the database decide who gets to refund:
const failAndRefund = async (errorMessage: string) => {
const result = await query(
`UPDATE generations SET status = 'failed', error_message = $1
WHERE id = $2 AND status = 'processing'`,
[errorMessage.substring(0, 500), generationId],
)
if (result.rowCount && result.rowCount > 0) {
await addCredits(userId, creditsCharged)
}
}
Only the caller whose UPDATE actually flips the row from processing to failed sees rowCount > 0, so only that caller refunds. A SELECT followed by an UPDATE looks equivalent and is not: two pollers can both read processing before either writes. We learned that the expensive way, with a polling endpoint that refunded the same failure on every poll.
Where this approach falls short
A one-sentence prompt gives the user no dial. If you need to control grain strength or skin detail per image, a slider-based tool is the better fit. A generative re-render can also shift very fine details, and GPT Image 2's safety filter refused about 1 in 20 of these requests in early September 2026, which is why the refund path matters.
FAQ
Why an iPhone 12 and not the latest model? Nothing magic; it is a very common, well-represented camera. Users do edit it: we see iPhone 13 to 17 in their prompts.
Does naming a camera work with other models? We only tested GPT Image 2. The idea, naming a familiar device instead of describing its output, should transfer, but test it.
Why not just add grain in post? Grain fixes the surface only. Plastic lighting, colour grades and over-smooth skin are structural, and a texture overlay cannot touch them.
The tool is at sparkpix.ai/ai-image-humanizer, 5 credits per image with the first image free. For how it compares with nine other tools, see Best AI Image Humanizers in 2026.
Top comments (0)