Thai OCR: extracting document text you can verify
Select and test Thai OCR for scanned documents, tables and critical fields.
Thai OCR: why government documents still get misread
Thai OCR fails on government documents for reasons that have little to do with the language model: tone marks sit on vowels, stamps cover characters, and old fonts print strokes that no longer look like letters. The fix is a pipeline — preprocess, detect, recognise, post-correct — measured per field, not by one accuracy number.
Where Thai text breaks
Thai stacks vowels above, below, before and after the consonant, then puts a tone mark on the vowel, so several marks share one cell and collapse at scan resolution.
Thai also encodes the same visible vowel two ways: sara am as one character, or nikhahit plus sara aa. They look identical, compare as different strings, and break exact-match scoring. Normalise before comparing, and write the rule into the contract.
Six reasons government documents get misread
Tone marks and stacked vowels
The marks are small, low-contrast and easily merged with the vowel beneath them. A recogniser can read the base consonant correctly and still return the wrong word, an error a reviewer skimming for meaning will miss.
Stamps and overlays
Registration stamps, paid stamps, signatures and seals sit on the text. A red stamp over black type reduces contrast exactly where the characters are; channel separation can suppress some stamps, but nothing suppresses a stamp in the same ink as the text.
Handwriting and signatures
Filled forms mix printed labels with handwritten entries. Handwritten Thai names, addresses and amounts are a different problem, and treating them as one is how projects over-promise.
Old fonts and dot-matrix printing
Typewriter-era Thai fonts, faxes and dot-matrix forms print strokes a modern recogniser never saw in training. One letter can look different on two pages of the same document.
Skew, curvature and page edges
A scanned page is rarely square. Two degrees of rotation, a gutter shadow or a phone photo shift characters away from where the model expects them. Deskew and dewarp before recognition, and crop the edge so it is not read as a character.
Thai numerals, dates and formats
Government forms use Thai numerals, Buddhist Era dates and layouts that vary by department. A correct string can still be the wrong value: ๒๕๖๙ is 2569 BE, or 2026 CE, and a date field that accepts both will produce both.
The pipeline that works
Preprocess
Deskew, dewarp, denoise, crop borders, fix orientation and separate colour channels to suppress stamps. Upscale until strokes separate: blaming a vision model for a low-resolution fax is expensive. Keep the original image so a reviewer can check the work.
Detect
Find text blocks, tables, checkboxes and handwriting, and treat stamps as their own class. Reading a stamp as text is worse than ignoring it: it produces confident nonsense in a field that should have been flagged.
Recognise
Run printed Thai through a Thai-capable recogniser or a vision model prompted for Thai, cell by cell where layout matters. Keep confidence at line or word level. Route anything below your threshold to review instead of guessing.
Post-correct
Normalise sara am and whitespace, convert Thai numerals where the field expects Arabic digits, resolve Buddhist Era dates, then validate: a checksum on the national ID, a real date, a province from the fixed list, an amount matching its written form. Constrain dictionary correction so it cannot rewrite names or numbers.
How to measure it
| Metric | What it tells you | How to compute it | Where it misleads | |---|---|---|---| | Character error rate (CER) | How many characters are wrong | Substitutions plus deletions plus insertions, divided by reference characters, after agreed normalisation | Treats every character equally: one wrong digit in an ID looks minor, not like a failed field | | Word error rate (WER) | How many words are wrong | Edit distance over tokens from one fixed tokenizer | Thai has no spaces, so the figure depends on the segmenter and compares only within one tokenizer | | Field accuracy | Whether the extracted value is usable | Exact match per field, reported per document type | Hides layout failures where a correct value lands in the wrong field | | Seconds per page | Throughput and user wait | End-to-end time at the 50th and 95th percentile, excluding human review | Ignores review time, often the larger operational cost | | Straight-through rate | Share of pages needing no human | Pages accepted without review, divided by pages processed | Rises if you lower the review threshold, which hides errors |
Test on your own worst pages, with two independent transcriptions and an adjudicated reference, and report by document type; one blended number across clean and degraded pages tells you nothing.
Vendor checklist
- Will you benchmark on our pages, not your demo set, and share the reference transcriptions?
- Do you report field accuracy per document type, or only one overall accuracy figure?
- How do you handle sara am normalisation, Thai numerals and Buddhist Era dates?
- What happens to stamps and handwriting: recognised, ignored or flagged?
- Where are pages stored, for how long, and can this run in our environment?
- What drives cost per page — resolution, page count, model calls, review?
- Who owns the correction rules when a new document type appears?
FAQ
Is a general vision model good enough for Thai OCR?
For clean, flat, modern documents it can be. For scanned forms with stamps, old fonts and handwriting, the model is one component among several; preprocessing and validation do most of the work. Judge it on your pages, not a product demo.
Why does the same page read correctly one day and wrongly the next?
Recognition is probabilistic: small changes in image quality, cropping, preprocessing or model version change the output. Confidence scores and a review queue make that variability safe to operate; a single accuracy claim does not.
Can it handle handwritten Thai forms?
Short handwritten entries such as dates, amounts and ID numbers can be recognised with a review step. Free-form handwritten notes still need a person. Plan the workflow around review, and budget the reviewer's time as part of the system.
Next step
Send a sample of the documents you actually need to read, bad scans included. We will tell you which fields can be automated, which need review, and how we would measure both. Start at seansolution.tech/contact, or email [email protected], call +66 94-865-9978, or message us on LINE at lin.ee/WQlPJc5.
Tell us about your problem and data to assess a suitable approach.
Discuss your project