Convert JXL to TXT

Every other pair on this site takes a file and writes the same file in another form. This one does something categorically different: it looks at a picture and writes down what it thinks the picture says. There is no mapping from a JPEG XL to a text file, because a text file cannot hold an image and an image does not contain characters — only shapes that look like them.

That is why the output is labelled a guess rather than a result. A converter either works or throws an error; a recogniser returns text that looks like text whether or not it matches the page. Everything below is about narrowing the gap between those two things, and the single most useful habit is reading the output against the original before you rely on it.

JPEG XL lost the browser fight but it did not lose everywhere, and the places it survived are exactly the places documents live. The registry lists archival and photography as its uses, and archival is the honest one: digitisation projects picked it because it does lossless well, holds high bit depths, and stores a scanned page in fewer bytes than anything of PNG’s generation.

The other common route is Apple. Safari has supported JPEG XL since version 17, so a file saved from the web on a Mac or an iPhone can land as .jxl without anyone choosing it. Either way the person who ends up here did not pick the format — they were handed a page of words wrapped in an image format, and they want the words.

Every other image path on this site decodes the file to pixels first. This one does not: the file goes to the recognition engine as it is, because that engine has its own loader and forcing the image through a canvas would flatten transparency to black — which on a scan of white paper is the difference between readable and unreadable.

The consequence is that your browser is not part of this at all. The file is read to raw bytes and passed straight to the recogniser, so the only decoders that can act on it are the six compiled into the recognition engine: BMP, JPEG, PNG, PBM, WebP and non-animated GIF. JPEG XL is not one of them, and no JPEG XL decoder exists anywhere in the WebAssembly core this site serves.

This page used to say that reading a JXL depended on which browser you were in, and named Safari as the one where it worked. That was wrong, and it is worth correcting plainly rather than quietly: Safari has displayed JPEG XL since version 17, but the recogniser never asks the browser to display anything, so Safari fails here exactly as Chrome does. Nothing you can change in your browser makes the one-step version work.

What does work is one extra conversion. Take the JXL to PNG on this site, then read the text out of the PNG. That first step carries its own JPEG XL decoder compiled to WebAssembly rather than asking the browser for one, so it runs the same in Chrome as in Safari — which is the part worth knowing, because it is the reverse of what the old wording implied. PNG is the format to pick for the file in between: it is lossless, so every stroke the recogniser needs survives, where JPEG would recompress the letterforms for no benefit. The PNG is scratch — delete it once you have the text.

English, German, French and Spanish have models available, and the setting is not optional in practice. The recogniser matches shapes against the letterforms and the vocabulary of one language at a time, so a French page read as English does not produce an error — it produces fluent-looking rubbish, because every shape was matched to the closest thing in the wrong dictionary.

It matters most for accented characters and for mixed content. A German document with English technical terms in it reads better with German selected than with either guessed, because the model is choosing between candidate words as much as candidate letters. Set it before you convert; there is no way to tell afterwards from the output alone that it was wrong.

Recognition needs enough pixels per character, and that is the variable that separates a near-perfect result from a useless one. A page scanned at 300 dpi has plenty. A photograph of a page taken from across a desk, a screenshot scaled down to fit a document, or an image a chat application recompressed on the way through may not.

Enlarging the image afterwards does not help. Scaling up adds pixels without adding information and usually makes the result worse by softening the letterforms the recogniser is trying to match. If a result comes back poor, the fix is upstream: rescan at a higher resolution, photograph the page closer and square on, or find the original file rather than the copy that was passed around. Angle is the other half of the same problem — a page shot from above at a slant gives every line a slight curve and every character a slight shear, and the recogniser has no model of perspective with which to undo it. Flat on a table, camera parallel to the page, is worth more than any setting on this form.

A text file has no columns, no cells, no font and no position. What you get is the characters the recogniser found, in the order it read them, and that is a genuine loss of structure rather than a formatting preference. A table comes back as a run of values with the columns gone, a two-column page can interleave its lines, and a heading arrives as an ordinary line like any other.

The line breaks are left exactly as they were seen, with no attempt to join wrapped lines or collapse blank ones. That looks untidy and is deliberate: a poem, an address block and a table all lose meaning when their line breaks are tidied, and a converter has no way to tell which of those it is looking at. What the recogniser saw is what you get.

The characteristic failure is not a garbled mess, which you would notice. It is a single plausible substitution in a number or a name — a 5 read as an S, a 1 read as a lowercase l, a zero read as a capital O — inside a paragraph that is otherwise perfect. Reference numbers, account details, dates and prices are where this does real damage, because they are exactly the strings with no context to correct them.

So the working rule is to proofread anything that will be acted on rather than read. Skimming a recovered paragraph for sense catches the obvious failures; checking a sort code character by character is the only thing that catches the dangerous one. Code and command lines carry the same hazard in a sharper form, because the characters that matter most there are the ones that look alike — the digit one against a lowercase l against a pipe, zero against capital O — and a misread produces something that looks correct and does not run. The recogniser has no notion of confidence it can hand back, and that limitation belongs on this page rather than in a footnote.

Text recognition is by a wide margin the slowest engine here. The first conversion also has to fetch the WebAssembly core and the language model before it can start, so the initial run feels considerably worse than the ones after it — the model stays loaded for the rest of the session.

The progress bar deliberately tracks only the recognition itself rather than the download and initialisation, because a bar that fills to full while nothing has been read and then sits still is worse than one that starts late and means something. A single page takes seconds. A folder of them takes seconds each, in sequence, on your processor.

The recognition engine, its WebAssembly core and all four language models are served from this site’s own origin. That was work rather than a default: the library fetches all three from a public CDN unless every path is overridden, which would have meant three requests to a third party carrying your address and the URL of the page you are on.

The image itself would never have been sent either way — but somebody reading a payslip should not have the fact of it announced to a content network. There is a test in the repository that fails if a CDN URL ever reappears, because a default that convenient comes back on the next upgrade. The result is that a scan of something private is processed entirely on your own machine, with nothing to delete afterwards.

If the document started life as a PDF with a text layer, do not photograph or export it and recognise the picture — pull the text straight out of the PDF instead. That is an exact extraction rather than a guess, and it keeps every character the author typed. Recognition is for the case where no text layer exists, which is any scan and any photograph.

And if you need the picture rather than the words — to file it, to print it, to send it to somebody — this is the wrong page entirely. Text recognition throws away everything that is not a character, including the layout, the signatures, the stamps and the photographs. Convert the image as an image, and use this only when what you actually want is something to paste.