How it works

Why this is harder than it looks

Colouring code is the easy half. Editors have done it for decades, and so does this. The hard half comes first: a document does not tell you where the code is.

When somebody pastes a function into Word, the result is just a sequence of paragraphs. Some are sentences, some are source, some are the program's output, some are equations, and by the time the file has been through a PDF export, a copy-paste and a template change, whatever formatting once distinguished them may be gone entirely. Before a single character can be coloured, something has to decide which lines are which — and be right often enough to be useful while being cautious enough not to mangle the prose.

That decision is the whole product. Everything else follows from it.

The four steps

1. Your file is read, not converted

A .docx is unpacked and a .pdf has its text layer extracted, down to where every line sits on the page, how it is set, and what surrounds it. Two things matter here that most extractors get wrong, so they are handled explicitly: multi-column layouts are read column by column rather than straight across the page, and tables are recognised as tables rather than being flattened into lines.

Nothing is rendered, rewritten or re-typeset at this stage. The original file is kept intact so it can be edited later rather than reconstructed.

2. Every line is classified

Each line is sorted into one of four kinds — source code, terminal output, an equation, or ordinary prose — by a detector that weighs both the line itself and the company it keeps. Context matters as much as content: real code arrives in runs, a comment belongs to the block it sits in, output belongs under the program that printed it, and a lone ambiguous line in the middle of a paragraph is almost always just a sentence.

This step is deterministic and it runs in well under a second, whatever the length of the document. There is no model involved and no network call. The same file always produces the same answer.

3. What was found gets coloured

Only now does anything become a colour. Code blocks are identified by language where possible, tokenised, and painted in whichever of the eleven IDE themes you have selected — VS Code Dark+, One Dark, Dracula, Monokai, Nord, Solarized and the rest. Terminal output gets its own darker surface, because a program and its output should not look alike. Equations are typeset on white, the way they are printed.

Blocks that are clearly code but do not match a known language are still highlighted, using shared rules, and labelled "Unknown" rather than guessed at. See supported languages.

4. The document is written back out

Ask for the format you arrived with and your original file is edited. Only the parts of it that belong to code are rewritten; every other paragraph keeps its original bytes, so its font, size, spacing, colour and style cannot drift.

Ask for the other format and the document is rebuilt, carrying across page size, margins, point sizes, weights, colours, indentation and line spacing. Images and tables do not survive that trip, and the exact typeface cannot. The tool tells you which of the two you are about to get before you press the button. More on the difference.

You get the last word

No detector is right every time, so the result is built as something you can correct rather than something you have to accept.

• Every line shows a confidence figure. Not a verdict dressed as certainty — an actual number, per line, that you can scan.
• A control jumps to the least certain lines. On a typical document that is a handful out of hundreds. Check those and you have checked the document.
• Selecting any passage lets you re-mark it as code, terminal output or an equation, or unmark it back to plain text. "Unmark everywhere" applies the same correction to every identical line in the file at once.
• Your marks win. They are not suggestions the detector may override; they flow straight through to the screen, the PDF, the Word file and the HTML.

The optional second opinion

One button, Refine output with AI, asks Google's Gemini about the lines the detector itself flagged as doubtful. Three things about it are worth being precise on:

• It is opt-in. Nothing leaves until you press it.
• It sends only the uncertain lines and just enough of their neighbours to make sense of them — not your file, and not the whole document.
• Anything it changes is badged in the result, so you can see what the model touched and put it back if you disagree.

The reasoning behind that split — algorithm for the unambiguous majority, model only for the genuinely doubtful remainder — is set out on why not just use AI.

Where your document goes

Reading, detection and writing all happen on our server rather than in your browser. The file travels over HTTPS, is held in memory, is never written to disk, and is discarded within twenty minutes of your last action or the moment you close the tab, whichever comes first. It is never used to train anything and never passed on. The privacy page is the detailed version.

Why the rule set is not published

An earlier version of this page listed every signal, every weight and every threshold the detector uses. That has been taken down deliberately, and it is fairer to say so than to quietly shorten the page.

The detection rules are the tool. They took a long time to get right, most of that time spent on the awkward cases — comments stranded above a block, output that looks like source, prose that happens to be full of brackets, tables that read like code, equations broken across three lines by a page break. Publishing the table hands that work to anyone who wants to reproduce it, and it is not information that helps you use the tool.

What is still published is everything that affects you: what the tool does, what it does not touch, where your file goes, where it is weak, and a confidence figure on every line so you can judge the output rather than trust it. The limitations page keeps listing the failure modes as they are found, including the ones that are still unfixed.

How well does it work?

A Word file whose listings were set in a monospaced font or a code style is close to a solved case: the document itself says "this is code" and the tool believes it. Plain unformatted text is harder and depends on the code being recognisable as code. A PDF sits in between, because a PDF has thrown away most of what a Word file knew about itself — why that is.

The weakest case, by design, is the isolated one-line snippet. A single ambiguous line with no code around it is treated as prose, because a false positive in the middle of a paragraph is worse than a missed line you can mark yourself in two clicks.