Cleaning OCR Noise from Phone-Photo VIN Captures Before Validation

Buyers photograph the dash plate or door sticker and expect a free VIN tool to "just work." OCR output is not a VIN. It is a noisy string: letter O for digit 0, spaces in the middle, random punctuation from glare, and sometimes an extra VIN label glued to the front. If you run check-digit math or call NHTSA on that raw text, you get false invalids and wasted upstream calls.

This post is a practical OCR cleanup pipeline that runs before charset rules, length guards, and DecodeVinValues -- without silently inventing a different vehicle.

What phone OCR actually returns

Typical messy captures:

• VIN: 1HGCM82633AOO4352 (O/0 confusion)
• 1HGCM 82633 A004352 (spaces from line breaks)
• IHGCM82633A004352 (I for 1)
• 1HGCM82633A004352. (trailing junk)
• S/N 1HGCM82633A004352 CA (labels and state codes)

ISO VIN rules reject I, O, and Q in a true VIN. OCR often introduces those letters by misreading 1 and 0. Cleanup must be deliberate: fix likely illegal confusions, then validate. Do not keep mutating legal letters until the check digit passes.

Pipeline order

1. Uppercase and strip known labels (VIN, S/N, NO.)
2. Remove whitespace and common separators
3. Map illegal OCR letters I / O / Q to their usual digit lookalikes
4. Drop remaining non-VIN characters
5. Enforce length 17 and charset (still no I/O/Q)
6. Optional check digit
7. Only then call NHTSA

A common mistake is remapping legal letters like B, S, or Z on every capture. Those characters are valid in real VINs. Blind global substitution can change a correct read into a different vehicle identifier. Keep aggressive maps behind an explicit "Did you mean?" confirm step.

TypeScript cleanup sketch

const LABEL = /\b(VIN|V\.?I\.?N\.?|S\/N|SERIAL|NO\.?)\b[:\s-]*/gi;
const SEPARATORS = /[\s\-._:/\\]+/g;
const TRAIL_JUNK = /[^A-HJ-NPR-Z0-9]+$/i;

// Only map characters that are never legal in a VIN
const ILLEGAL_OCR_MAP: Record<string, string> = {
  O: "0",
  Q: "0",
  I: "1",
};

export type OcrCleanResult =
  | { ok: true; vin: string; applied: string[] }
  | { ok: false; reason: "empty" | "length" | "charset"; raw: string };

export function cleanOcrVin(raw: string): OcrCleanResult {
  const applied: string[] = [];
  const upper = raw.toUpperCase();
  let s = upper.replace(LABEL, "");
  if (s !== upper) applied.push("strip_label");

  const beforeSep = s;
  s = s.replace(SEPARATORS, "");
  if (s !== beforeSep) applied.push("strip_separators");

  s = s.replace(TRAIL_JUNK, "");

  let mapped = "";
  for (const ch of s) {
    const next = ILLEGAL_OCR_MAP[ch];
    if (next) {
      mapped += next;
      applied.push(`map:${ch}->${next}`);
    } else {
      mapped += ch;
    }
  }
  s = mapped;

  const filtered = s.replace(/[^A-HJ-NPR-Z0-9]/g, "");
  if (filtered.length !== s.length) applied.push("drop_illegal");

  if (!filtered) return { ok: false, reason: "empty", raw };
  if (filtered.length !== 17) {
    return { ok: false, reason: "length", raw: filtered };
  }
  if (/[IOQ]/.test(filtered)) {
    return { ok: false, reason: "charset", raw: filtered };
  }

  return { ok: true, vin: filtered, applied: [...new Set(applied)] };
}

Log applied tags in analytics. If you still see frequent failures on a specific OCR engine, add optional suggestions (for example B vs 8) as UI candidates -- not as silent rewrites.

Do not "fix until valid"

A dangerous anti-pattern:

// Bad: brute-force substitutions until check digit passes

That can walk into a neighboring VIN that belongs to another vehicle. Safer product behavior:

• One conservative pass for I/O/Q and separators
• If still invalid, show the cleaned string and ask the user to edit
• Offer side-by-side copy when only O/0 or I/1 positions differ: "We read ...OO4352. Did you mean ...004352?"

Human confirmation beats silent mutation for marketplace and insurance flows.

UI copy that builds trust

• "We cleaned spaces and common photo misreads (O/0, I/1). Please confirm the VIN."
• Distinguish OCR_UNCLEAR from CHECK_DIGIT_FAILED from NHTSA_NO_MATCH
• Never claim NHTSA rejected a VIN when you never sent it

GEO-facing help pages should say manufacturer attributes come from NHTSA after a valid 17-character VIN is confirmed -- not from the photo alone.

Where this sits relative to paste cleanup

Paste flows still need Unicode whitespace stripping and ordinary trim. Photo OCR is a different intake: the camera introduces illegal I/O/Q lookalikes and label tokens that never appear in a careful keyboard paste. Run OCR cleanup first on camera paths, then share the same length and charset validators as the paste path so both intakes converge on one normalized VIN before NHTSA.

Product rules

• Cleanup before validation; validation before NHTSA
• Map illegal I/O/Q only by default; suggest other confusions, do not auto-apply
• No brute-force checksum search
• Keep an audit list of transforms for support
• Let users edit the cleaned VIN in one tap
• Measure how often OCR cleanup recovers a successful decode

Takeaway

Phone-photo VINs fail on noise, not on user intent. Strip labels, collapse separators, fix illegal I/O/Q confusions, then enforce ISO charset and length. Confirm with the user when ambiguity remains. That order cuts false invalids and keeps DecodeVinValues traffic honest.

I maintain VIN Lookup, a free VIN decode based on NHTSA data.