Optical character recognition turns a picture of writing into writing. It is one of the oldest practical applications of computer vision and it works remarkably well now, which makes its failures more confusing than they used to be — because when it fails, it often fails quietly.
What the engine needs from your image
The single biggest factor is not file size, lighting, or the camera. It is how many pixels tall each character is. The recognition engine has to distinguish an 'e' from a 'c' and a '5' from an 'S', and below roughly twenty pixels of character height those distinctions stop being reliably present in the image at all.
This is why a screenshot of a document usually reads worse than the document itself, and why a photo taken from across a desk reads worse than one taken from above the page. It is also why "the file is 8 megabytes, it must be high quality" is the wrong intuition — a large file of small text is still small text.
Modern engines handle a lot of imperfection well: moderate skew, uneven lighting, a curved page, a slightly off-angle phone photo. What they cannot compensate for is missing resolution.
The empty-file failure
When text is too small or too blurry, most OCR engines do not raise an error. They return an empty result, because from the engine's point of view there was simply nothing recognisable in the image — that is a valid answer to the question it was asked.
A tool that passes that straight through hands you a text file containing nothing and marks the job successful. You then have to work out for yourself whether your document genuinely had no text, whether the tool is broken, or whether something else went wrong. That is the worst possible outcome, because it consumes your time to discover a failure the tool already knew about.
Filum treats an empty recognition as a failure and says so, along with the likely reason — usually that a higher-resolution version of the image is needed. No empty file is produced.
The confidence number, and what it is not
The engine reports its own confidence in what it read. It is worth showing, because in practice it tracks quality closely: it drops sharply on images that produce poor results.
It is not an accuracy score, and no honest tool should present it as one. It is the engine's belief about its own output, and an engine can be confidently wrong — particularly on an unfamiliar font or a language it was not given. Filum shows the number as the engine reports it, calls it what it is, and warns you to check the text against the image when it falls below 60%.
Language, format, and where the recognition runs
The language matters more than people expect. The engine uses a language model to disambiguate characters that are visually similar, so telling it the wrong language measurably degrades the result. Filum supports English, French, German, Spanish, Italian, Portuguese, and Dutch, each served from this site rather than a third-party network — so not even the language you selected is disclosed to anyone else.
It reads JPG, PNG, WebP, GIF, and BMP. HEIC — the default on iPhones — and TIFF are not supported, and you are told by name rather than left with a failure. For a scanned PDF the right tool is OCR PDF, which runs the same recognition across every page; if a PDF already has selectable text, PDF to Text extracts it directly, which is both faster and exact.
All of it runs inside your browser, on your device. That is not a technicality here: people photograph exactly the documents that should not be sent anywhere — identity documents, prescriptions, payslips, contracts. The engine is fetched once from this site and cached; the image never leaves your computer.