The ID photo looked genuine, so you approved it. Here is how edited ID images pass, and how to catch them.

Picture an applicant who has a real photo of a real national ID. It was taken months ago, in good light, and it has been sitting in a chat group ever since. It is not their ID.

They open it in an ordinary image editor. Two minutes later the name is theirs and the date of birth is theirs. If your flow compares a selfie with the portrait on the card, they paste their own face over the original too. Then they tap "upload from gallery".

Your system reads the text. The text is clean and sharp, because the original photo was. The selfie matches the portrait, because it is the same person. Everything agrees with everything else, and all of it came from the applicant.

That is the problem with a picture of a document. It is evidence the applicant made, about themselves, with full control over every pixel.

What an edited ID costs you

• An account in a name that is not real, or not theirs. Either the identity was invented on top of a genuine card, or a real person now has an account they never opened.

• A clean file. The record shows a readable document and a matching face. Nothing prompts a second look until the losses do.

• A hard question later. When a bank partner or regulator asks how you knew the document was genuine, "the picture looked fine" is not an answer you want to give.

We have not found a reliable public figure for how often edited ID images are submitted in African markets, so we will not offer one. Be careful with anyone who does.

Why an uploaded picture is weak evidence

Two different attacks hide behind the same upload button.

• The edit. A genuine document photo with the name, the dates, the ID number or the portrait changed.

• The reuse. An untouched photo of somebody else's ID, taken earlier and uploaded as if it were the applicant's own.

Neither needs special tools, and a gallery upload cannot tell them apart from an honest photo. The standard setters treat it that way. The US identity proofing guideline, NIST SP 800-63A-4 (opens in a new tab), requires providers that inspect documents by camera to use live capture, and explains why: live capture confirms that the document is physically present and that the image is "not a manipulated digital copy" (opens in a new tab). It is a US federal guideline, not your regulator's rulebook, but it is the clearest public statement of the risk.

What catches an edit

The useful checks have one thing in common. They compare the picture with something the applicant could not change.

• The document's own machine-readable data. Many IDs state their facts twice: once in print, and once in a barcode or a machine-readable zone. An editor who changes the printed name often leaves the other copy alone. The NIST guideline says that where a machine-readable zone or barcode is present, the inspection must compare it with the printed data for consistency (opens in a new tab).

• The chip. A passport, and some national ID cards, carry a chip defined by ICAO Doc 9303 (opens in a new tab). Its data is signed by the issuing country, so a changed name or portrait no longer matches the signature. Our guide to e-passport chip verification covers how.

• The government record. Where a database exists, the ID number is looked up and the name, date of birth and photo come back from the issuer, not from the image. Editing the picture changes nothing in the record. See document checks versus government database checks.

• A selfie compared with the right photo. A live face matched against the government's photo or the chip's photo defeats a portrait swap. A live face matched against the printed portrait does not.

• Live capture. Making the applicant photograph the document now, in the flow, rules out the lazy version of both attacks.

What does not catch it

• A sharp, readable image. Text recognition reads what is there. Edited text is usually easier to read than the original.

• Check digits. The machine-readable zone carries check digits, but ICAO Doc 9303 Part 3 (opens in a new tab) describes their purpose as letting readers verify the data was correctly interpreted. They are simple arithmetic on the visible characters. Anyone who edits the zone can recalculate them.

• Matching the selfie to the printed portrait alone. It proves the person resembles a picture they supplied.

• Live capture alone. A camera can be pointed at a screen or a reprint, and a feed can be replaced before it reaches the server. NIST says live capture makes forged media "more challenging" (opens in a new tab) to inject, which is not the same as impossible. We covered that in deepfakes and injection attacks.

What Toden does, and what it does not

Toden is built around the idea above: trust the sources the applicant cannot edit, and say plainly which one was used.

• Government record. In Nigeria, Ghana, Kenya, South Africa and Côte d'Ivoire, IDs are checked against the source database. The details you pass are compared with the record, and the selfie is compared with the record's photo.

• Chip. The mobile SDKs read the chip and the server authenticates it. A chip proven to be altered fails the verification with chip_not_authentic.

• Barcode and machine-readable zone. Where a document carries one that can be read, Toden reads it as well as the printed text. A document whose machine-readable zone names a different issuing country from the one selected is declined.

• Capture method. A workflow can allow scan or upload, scan only, or upload only. Scan only removes the gallery option from the document step.

• An honest label. Every pass carries an assurance level: chip, gov_db or document. facialMatchSource says which photo the selfie was compared with. You can send document results to review.

Now the limits.

• Toden does not claim to detect every edited image. It does not sell a forensic verdict on pixels.

• Outside those five countries there is no government database behind the check. A document without a readable chip is verified from the picture alone, at the lowest assurance level.

• The chip step needs a native mobile app, an NFC phone and an issuing country on Toden's trusted list. A browser cannot read a chip, and a missing chip never fails a verification.

• When no government or chip photo exists, the selfie can be compared with the printed portrait. That is weaker evidence and never raises the assurance level.

• Upload is allowed by default. Scan only is a choice you make, the upload option still appears if the applicant denies camera access, and it does not apply to images your own backend sends to the API.

• A camera in a browser can be a virtual one. Toden flags virtual cameras as a signal to route on. It is a signal, not proof.

What your regulator accepts as proof of identity differs by country, and we have cited a US guideline and an international standard here, not your local rules. This is not legal advice for your situation.

Questions to ask a provider

• When a verification passes, can you tell me what it was checked against: a government record, a chip, or only the picture?

• Which photo was the selfie compared with?

• Can I switch off gallery uploads, and what happens when the user denies the camera?

• Do you read the barcode or machine-readable zone, and what do you do when it disagrees with the print?

• In which of my countries is there a government source behind the check, and in which is there none?

• What kinds of edited image would you miss? Distrust a short answer.

Want to see how your own documents would be graded? Open a Toden workspace (opens in a new tab) or read how identity verification works.