Syntax Highlighter
Colour A Listing, Copy The Markup

What A Syntax Highlighter Does

A colour is a claim about what a piece of text is. Therefore a highlighted listing is easier to read. The reader learns the shape of a file before reading a line of it.

That is the whole job of this syntax highlighter. It splits the text into tokens, decides what each one is, and gives each class a colour.

It knows twelve languages, and it treats a string, a comment, a keyword, a number and a name as different things. Because the decision comes from a tokeniser rather than from a pattern match, a keyword inside a comment stays a comment.

Four outputs come out of one run. Escaped HTML to paste into a page, a word processor block, plain text, and a small stylesheet for the colours alone.

Everything runs in this tab. Therefore an unfinished listing gets coloured exactly like a shipped one.

How A Syntax Highlighter Splits Code Into Tokens

The reader walks the text once, carrying a state and a stack. At each character it decides whether it sits inside a string, a comment, a number or ordinary code. It emits a token when that state changes.

A keyword list per language supplies the rest. The list is short on purpose, because the useful question is which words the language reserves. That reserved list is what the standard documents publish.

Because the reader carries that state, a word inside a comment is not a keyword. This is the difference between a highlighter and a find and replace. It is also the first thing to look at when a coloured listing looks wrong.

A language that nests block comments needs a depth counter rather than a flag. One that allows a template literal needs a stack. Both are held so that an inner delimiter cannot end an outer block.

Nothing here changes the text a reader gets. A copy of the plain output is byte for byte what you pasted, which matters when the listing came out of a terminal.

Why The Output Escapes Before It Colours

Highlighted code is markup, and markup pasted into a page is markup the browser runs. So the angle brackets in a listing have to become entities before anything else happens.

That is not a formatting detail. A snippet copied from an issue tracker can carry a script tag, and a page that pastes it raw has just run a stranger's code.

Every output here escapes first and colours second. Because the escape happens before the tool writes a single span, a listing cannot introduce an element of its own.

The same rule covers an attribute. A comment that holds a quotation mark goes into the text of the span rather than into an attribute. So it cannot close anything early.

That is why the HTML output is worth copying from here rather than from an editor that colours for display only. The colours look identical and only one of them is safe to paste.

The Twelve Languages, And What Each One Needs

Four of them share a grammar with a sibling. JavaScript, TypeScript and JSON sit close enough together that one reader covers all three. CSS and SCSS share a reader the same way.

The C family adds a preprocessor line. The reader takes a hash line on its own before it tokenises the rest of the line. That is why include and define come out a different colour from the code around them.

Python and Ruby both need indentation awareness. A triple quoted string and a heredoc do not end at a newline. So the reader has to keep the string open across lines.

PHP and HTML interleave, so the reader switches mode at the opening tag. Because the two grammars are different, a single pass that ignored the switch would colour the HTML as though it were PHP.

SQL and Bash are the last two, and both are line oriented. A comment marker differs between them, which is the sort of detail that decides whether a listing reads correctly.

The Four Outputs, And When To Use Each

Escaped HTML is the first, and it is the one for a page. Each token becomes a span with a class. The tool escapes the text inside as entities, so the block drops into a post without any further work.

The word processor block is the second. Because a word processor ignores your stylesheet, the colours arrive as inline styles on each span, which survives a paste into a document.

Plain text is the third, and it keeps the indent and the line count without a single colour. Use it when the listing is going into a terminal or a commit message, where markup would be noise.

The stylesheet is the fourth. It carries the twelve colour rules with no markup attached. So a site that already wraps its own spans can adopt the palette without adopting the output.