ANSI escape codes: what each one does, and which standard defines it

What ANSI escape codes are

An escape sequence is a run of ordinary characters that a terminal reads as an instruction instead of printing. Nearly all the ones you meet start with the escape character followed by an opening bracket, then some numbers, then a letter that says what the numbers meant. When that final letter is m, the sequence is SGR — Select Graphic Rendition — and the numbers are the colour and attribute codes everybody calls ANSI colour codes.

The mechanism is simple and stateful: a code turns something on, and it stays on until something turns it off. That is why forgetting the reset at the end of a coloured string leaves the rest of your prompt the wrong colour, and why the codes are almost always written in pairs.

What is not simple is where the codes come from. Everything published about them presents one flat table, and it is three standards wearing one syntax. The plain colours and attributes are ECMA-48. The bright colours are an extension from IBM's aixterm. The 256-colour and true-colour codes are from ISO 8613-6, and xterm's reference describes those as marked in ECMA-48's fifth edition as reserved for future standardization — so the two codes a developer reaches for most are, in the standard everyone cites for them, reserved rather than defined.

How to use it

1. Paste terminal output, or pick a sample. The samples cover a build log, the same colour written the standard way, bright against ordinary colours, a fully portable sequence, and one with two things wrong in it.
2. Read the preview and the code table. The preview shows what a terminal would draw. Underneath, every SGR code found is listed with the standard that defines it and what it means, and the notes explain anything worth knowing about the sequence you pasted.
3. Build one and compare the spellings. Toggle bold, italic and underline, set a colour, and the same instruction appears twice — once with colons and once with semicolons. They mean the same thing and they are not interchangeable.

The separator nobody writes the standard way

The extended colour codes take subparameters: 38 says a foreground colour follows, then 5 and an index for the 256-colour palette, or 2 and three channel values for true colour. xterm's reference writes those subparameters separated by colons, and states plainly that it allows either colons, which it calls standard, or semicolons, which it calls legacy. Every tutorial, every library and every tool emits the semicolon form.

That is not a matter of taste, and the cost falls on whichever one you pick. Reading the source of the two most-used JavaScript renderers for this, both split parameters on the semicolon alone — one does a plain split on a semicolon, the other trims trailing semicolons and splits the same way — and neither contains a colon anywhere in its parameter handling. So the spelling the reference calls standard is exactly the spelling those libraries silently drop: the colour vanishes and the text renders unstyled, with no error anywhere.

There is a second casualty in the same line. The colon form of true colour carries a colour-space identifier before the red value, normally written as an empty field, so the full spelling has a gap in it that looks like a typo. The semicolon form has no slot for that field at all, which is why almost nobody knows it exists.

The honest summary is that there is no spelling that is both standard and widely handled, and that is why this page reports which trade-off your sequence is making rather than telling you one of them is correct. If you are writing for a terminal, the semicolon form is what terminals expect. If you are writing for a specification, the colon form is what it says.

What this page cannot tell you

The first sixteen colours are not fixed by anything. Codes 30 to 37 name a colour, not a value — what red actually looks like is whatever the reader's terminal theme sets it to, and the same output is a different picture in two windows side by side. The preview here uses one common set so there is something to look at, and that is a demonstration rather than an answer. Everything from index 16 upwards is different: the 216-colour cube and the 24-step grey ramp are defined by arithmetic, so those are exact.

The reserved-for-future-standardization phrase is xterm's characterisation of ECMA-48 rather than a quotation from it. ECMA-48 is published as a PDF that has resisted text extraction every time it has been tried here, so rather than paraphrase a document that could not be read, the attribution stays where it can be checked — with the reference that makes the claim.

Only SGR is interpreted. A sequence that moves the cursor, clears the screen or sets the window title is recognised, reported and then left alone, because rendering it would mean simulating a whole terminal rather than explaining a colour code. Sequences that do not begin with the escape and bracket pair — the older single-character controls, and the operating-system commands that set a title — are outside what this reads.

Finally, this describes what the codes mean, not what your particular terminal does with them. Blink is widely ignored. Faint is ignored by some terminals and rendered as a dimmer colour by others. Double underline is patchy. A terminal is allowed to do nothing at all with a code it does not implement, and most of them quietly do exactly that.

Why is it free?

Parsing escape sequences is string handling, and it runs in your browser. There is no server in the loop, so there is nothing to bill for and no account to create.

Nothing is uploaded, which matters more than usual here — pasted terminal output tends to contain paths, hostnames and the occasional token. Reload the page and it has forgotten all of it.