PAN redaction gets far less attention than Aadhaar and is arguably the easier number to misuse. It is also the one where the masking format is less well known, and where naive detection goes wrong in a specific and instructive way.

A PAN is ten characters: five letters, four digits, one letter. ABCDE1234F. It appears on income tax filings, demat accounts, mutual fund records, property transactions, salary slips and most financial onboarding in India. It is a permanent identifier — the name says so — and unlike a card number it cannot be reissued if it leaks.

What a masked PAN looks like

The convention is to keep the first two characters and the last one, obscuring the middle seven: ABCDE1234F becomes ABxxxxxxxF.

That is not an arbitrary split. Each position in a PAN carries meaning, and the visible characters are chosen to preserve the parts that identify a category rather than a person.

PositionMeaningMasked?
1–3Alphabetic series issued by the departmentPartly — first two kept
4Holder type: P individual, C company, H HUF, F firm, T trustYes
5First letter of the surname, or of the entity nameYes
6–9Sequential numberYes
10Check characterNo

The fifth character is the one worth noticing. It is the first letter of the holder's surname, which makes an unmasked PAN a small piece of identity information in itself — enough, combined with a name you already half know, to confirm a guess.

Why PAN misuse is easy

PAN is used simultaneously as an identifier and as a credential, which is the combination that causes trouble. It is printed on documents shared routinely, and it is also accepted as proof of identity in flows where nobody verifies it against anything.

The documented patterns of misuse are not exotic:

The common thread: the damage lands on the person whose number it is, and unwinding it is slow. You can freeze a card. You cannot reissue a PAN.

Where naive PAN detection goes wrong

The obvious regex is [A-Z]{5}[0-9]{4}[A-Z], and it fails in both directions on real documents. The failure modes are worth knowing because they tell you what a detector is actually doing.

False positives from concatenated tokens

This is the interesting one. OCR returns a document as a stream of tokens with bounding boxes, and a detector that joins adjacent tokens to recover a number split by glare will sometimes join two unrelated ones.

The classic case is a date of birth. Merging the tokens either side of DOB: 07/06/1967 can produce a ten-character string that is structurally a valid PAN — five letters, four digits, a letter — assembled entirely out of things that are not a PAN. A detector that accepts it masks the wrong region and leaves the real number untouched, having reported success.

The defence is to allow token merging only for exact reads, and never to accept a repaired concatenation. A single token that is nearly a PAN may be worth repairing; two tokens glued together and then repaired is manufacturing a number.

False positives from other identifiers

GSTIN contains a PAN. A GSTIN is fifteen characters: two state-code digits, the ten-character PAN, an entity digit, the letter Z, and a checksum. So a document showing a GSTIN contains a structurally perfect PAN inside it. Whether that should be masked depends on the document — a GSTIN is public information published on the GST portal, so masking part of it usually serves no one and makes a business document unusable.

TAN is ten characters too, in a different shape: four letters, five digits, one letter. Close enough that a loose pattern catches it.

False negatives from the character set

OCR confusions cluster around the letter/digit boundary: O and 0, I and 1, S and 5, B and 8. A PAN puts letters and digits directly adjacent, which is precisely where those confusions are hardest to resolve from shape alone.

Position helps here, because a PAN's structure is known. A character read as O in position seven, where only digits are valid, is a zero. That constraint recovers a substantial number of otherwise-missed reads — and it is only available to a detector that models the format rather than pattern-matching it.

The check character in position ten adds a further filter, in the same way the Verhoeff checksum does for Aadhaar: a candidate that fails it is unlikely to be a real PAN, which removes a large share of remaining false positives.

When to mask a PAN

The same reasoning as Aadhaar, arrived at from a different direction. Mask it whenever the recipient does not need to verify it against something.

The test is the same one worth applying to any identity document: is the recipient going to check this number, or keep it? If they are keeping it, the masked version does the job and does not create a liability for either of you.

Doing it

The free browser tool masks a PAN card without uploading it — the detection runs on your own machine, so the document never reaches a server. For volume, POST /api/v1/mask-pan takes the same shape as the Aadhaar endpoint: one multipart request, the redacted document in the response body, and an X-Masked-Count header that tells you whether anything was found.

As with Aadhaar, the header is the part that matters. A 200 with a count of zero means the number could not be read and the original came back unchanged — not that the document was clean.

Questions

How is a PAN number masked?

The first two characters and the last one stay visible and the middle seven are obscured, so ABCDE1234F becomes ABxxxxxxxF. The split is not arbitrary: the fourth character encodes holder type and the fifth is the first letter of the surname, so masking them removes the parts that identify a person while leaving enough for record matching.

Why is a PAN worth masking?

Because it is used as an identifier and as a credential at the same time, and it is permanent. High-value transactions are reported to the tax department by PAN, credit bureau records are keyed on it, and it is accepted as identity proof in flows where nobody verifies it. You can freeze a card after a leak; you cannot reissue a PAN.

Why do PAN detectors mask the wrong text?

Usually because they join adjacent OCR tokens to recover a number split by glare, and sometimes join two unrelated ones. Merging the tokens either side of a date of birth can produce a structurally valid PAN — five letters, four digits, a letter — assembled entirely from things that are not a PAN. The detector then masks that region and leaves the real number untouched while reporting success.

Does a GSTIN contain a PAN?

Yes. A GSTIN is fifteen characters: a two-digit state code, the ten-character PAN, an entity digit, the letter Z and a checksum. So any document showing a GSTIN contains a structurally perfect PAN inside it. Whether to mask it depends on the document — a GSTIN is public information on the GST portal, so redacting part of it usually serves nobody and makes a business document unusable.

When should I not mask my PAN?

Where a regulated entity is genuinely verifying it: income tax filing, opening a demat or trading account, and similar flows where the number is required rather than filed. The test is whether the recipient will check the number or merely keep it. If they are keeping it, the masked version does the same job without creating a liability.

Masking Aadhaar at volume?

One REST call takes a document and returns it redacted, for KYC and document pipelines. Free browser tools for everything smaller — those never upload the document at all.

Request API access