Colors

TeX has no concept of colour. Knuth's engine assembles a page out of boxes and glue, and nowhere in that model is there room for colour — there is no colour primitive in TeX at all. So what does LaTeX's xcolor package actually do? It leaves a note for the output driver. Write \textcolor{red}{…} and TeX slips a \special — "red from here" — into the output file; the actual painting is done later, by whatever produces the PDF. Once you know that one fact, almost everything puzzling about colour in LaTeX explains itself. This page follows the whole path: loading \usepackage{xcolor}, then \textcolor, \colorbox and \pagecolor, then \definecolor and colour models, then the red!30!white mixing notation — and finally the trap at the end, that the colours on your screen are not the colours that come off a printing press.

\usepackage{xcolor} vs the color package: which one to load

The answer is always \usepackage{xcolor}. It is a superset of David Carlisle's color package: it inherits every one of that package's commands and adds colour mixing, extra name sets and model conversion on top. It was written by Uwe Kern (2003–2021) and has been maintained by the LaTeX Project since 2021; TeX Live 2024 ships v3.01, dated 15 November 2023. Its guiding principle is driver independence — the same colour specification is interpreted the same way whether you go through pdfTeX or through dvips.

That insistence on driver independence is still visible in how the options are designed. The old color package used to switch on the 68 dvipsnames colours silently whenever a dvips-family driver was selected — which produced documents that compiled on the author's machine and died with an undefined colour the moment someone tried pdfTeX. xcolor dropped that behaviour: it hands out those names only to people who ask for them by writing dvipsnames, and in exchange makes them work under every driver. Out of the box you get 19 base colours; on top of those you add dvipsnames (68 colours), svgnames (151 names) or x11names (317 names) as needed. If you want to colour a table, the table option brings colortbl along with it.

\usepackage{xcolor}                   % 19 base colours, always available
\usepackage[dvipsnames]{xcolor}       % + 68 cmyk names from the dvips driver
\usepackage[svgnames]{xcolor}         % + 151 names from the SVG 1.1 spec
\usepackage[x11names]{xcolor}         % + 317 names from the X11 rgb.txt
\usepackage[dvipsnames,svgnames]{xcolor} % sets can be combined
\usepackage[table]{xcolor}            % also loads colortbl for coloured tables

The difference between \textcolor and \color, plus \colorbox and \fcolorbox

\textcolor{red}{text} colours only the argument you give it, while \color{red} is a switch that stays on until the enclosing TeX group closes. The two are not really separate mechanisms: \textcolor is just \color with the braces supplied for you — the xcolor documentation says exactly that. So if you forget the outer { } in {\color{blue} …}, the rest of the document turns blue. Read the other way round, it means that a \color used inside a section or an environment reverts by itself when that environment ends. \textcolor additionally calls \leavevmode, so putting it at the very start of a paragraph does not break the indentation.

This word is \textcolor{red}{red}, the rest is not.

{\color{blue} Everything from here to the closing brace is blue.} Back to black.

% the whole box gets a background; the frame colour comes first
\colorbox{yellow}{highlighted}
\fcolorbox{red}{yellow}{red frame, yellow fill}

\colorbox{colour}{text} paints a background, and \fcolorbox{frame}{fill}{text} sets frame and fill separately — frame first, fill second. There is one trap here that is easy to fall into. A \colorbox is, as the name says, a box, and its contents cannot break across lines. Highlight a long sentence and it will run straight off the edge of the type area, with an Overfull \hbox warning to show for it. That is fine for a few words, but if you want to shade whole sentences, move to something that understands line breaking, such as soul's \hl or tcolorbox. Note too that colour arguments belonging to other packages — soul's \sethlcolor is the example the manual itself gives — may not accept a colour expression like red!30!white directly. Give the mix a name with \colorlet first and pass the name instead.

Why \pagecolor ignores TeX groups: colour is a \special

\pagecolor{black} changes the background of the current page and every page after it. Unlike \color, it is a global declaration that does not respect TeX groups: writing {\pagecolor{black} …} does not restore anything at the closing brace. To undo it you must say so explicitly, with \nopagecolor (back to transparent) or \pagecolor{white}. This is the first thing that trips people up when they only want a black title page, so the standard move is to put the cancellation right after \maketitle. If what you actually want is a frame or a watermark on particular pages rather than a flat background, the eso-pic family of tools is the better fit.

\pagecolor{black}\color{white}
\maketitle
% \pagecolor is global: it must be cancelled by hand
\nopagecolor\color{black}

That global behaviour is not bad manners; it is the nature of the \special mentioned at the top. Colour is not stored inside TeX's boxes — it is only a note left in the output file. So when the page changes, the note no longer reaches its destination. Early pdfTeX had a famous consequence of this: colour set before a page break was simply lost on the next page. The workaround was a package called pdfcolmk, which used LaTeX's marks mechanism to restate "this page begins in this colour" at the top of every page. pdfTeX 1.40, released in 2007, built in a colour stack, and the trick became unnecessary. Today pdfcolmk is a do-nothing compatibility stub, and xcolor's fixpdftex option is a relic that only warns Package option 'fixpdftex' is obsolete and ignored. In modern pdfLaTeX, colour survives a page break.

When to use \definecolor and when to use \colorlet

\definecolor{name}{model}{spec} builds a colour out of numbers; \colorlet{name}{colour} builds one out of a colour you already have. If the brand guidelines hand you "#1B3A6B", you want the first; if the request is "the same blue as the body text, only darker", you want the second. Either way, write it once in the preamble and the name behaves like red or blue from then on. \colorlet accepts the colour expressions covered in the next section, which makes naming a mixture its most useful role in practice: \colorlet{accent}{blue!30!black}. Route every colour in the document through a name like that, and retuning the whole palette means editing one line of the preamble.

\definecolor{myblue}{rgb}{0.2,0.4,0.8}   % from numbers
\definecolor{brand}{HTML}{1B3A6B}        % from a web hex code
\colorlet{accent}{blue!30!black}         % from an existing colour
\colorlet{ruleline}{brand!25}            % a 25 % tint of the brand colour

rgb, RGB, HTML, cmyk, gray: which colour model to choose

The second argument to \definecolor is the colour model — the scheme in which a colour is written as numbers. In practice the choice is easy: match the form of the numbers you were given. A web colour code calls for HTML, a design tool that emits values from 0 to 255 calls for RGB, and a four-colour specification from a print shop calls for cmyk. xcolor converts between them internally, so the same colour written in a different model comes out the same.

% four spellings of one orange
\definecolor{o1}{rgb}{1,0.5,0}
\definecolor{o2}{RGB}{255,128,0}
\definecolor{o3}{HTML}{FF8000}
\definecolor{o4}{cmyk}{0,0.5,1,0}

% the model can also be given inline, in brackets, at the point of use
\textcolor[HTML]{FF8800}{a one-off orange}
\color[gray]{0.5}

The model can equally be named at the point of use, in brackets. For a one-off colour that does not deserve a name, \textcolor[HTML]{FF8800}{…} or \color[gray]{0.5} will do. The odd one out in the table is wave: hand it a visible wavelength in nanometres and xcolor computes what that wavelength looks like — \definecolor{sodium}{wave}{589} gives the yellow-orange of the sodium D line. For a figure about optics or spectra, no specification is more honest. named, by contrast, is a pseudo-model that holds no numbers at all; it exists to refer to names already loaded by options such as dvipsnames. Day to day, writing the colour name directly is enough.

What the ! in red!30!white actually does: mixing colours

The ! separates the parts of a mixture: colourA!number!colourB means "that percentage of A, the rest B". Expand red!50!blue and you literally get rgb 0.5,0,0.5 — the purple that sits exactly halfway between them. Leave colour B out and the remainder is taken to be white: red!20 expands to 1,0.8,0.8, twenty per cent red over eighty per cent white, a pale pink. This is the point at which xcolor decisively leaves color behind. You no longer need an ever-growing list of colour names; you derive the shade you need from the colours you already have.

• red!50!blue — half red, half blue; expands to rgb 0.5,0,0.5
• red!20 — 20 % red, the rest white: the standard way to make a tint
• blue!30!black — 30 % blue, 70 % black: the standard way to make a shade
• -red — a leading minus gives the complement; -red is exactly cyan (rgb 0,1,1)
• green!40!yellow!60 — expressions chain, mixing left to right
• gray!15–gray!25 — about the right strength behind text; a saturated colour is hard to read on

A colour expression is accepted anywhere a colour is expected: in \textcolor{blue!30!black}{…}, in \colorbox{yellow!40}{…}, in the arguments of \definecolor and \colorlet, and in \rowcolor{gray!15} when you shade a table. In practice the winning habit is not to scatter mixtures through the text but to name each one once with \colorlet. If accent and accent!15 between them cover your headings, your boxes and your zebra stripes, changing the tone of the document is one line in the preamble. Write blue!30!black in forty places instead, and changing your mind later becomes a search-and-replace job.

\colorlet{accent}{blue!30!black}
\colorlet{accentbg}{accent!15}

% then, in the body
\textcolor{accent}{a heading}
\colorbox{accentbg}{a quiet highlight}
\fcolorbox{accent}{accentbg}{framed and filled}

Which colour names are available: from 19 to 752

Even with no options at all, these 19 colours are always there. They are defined in xcolor.sty itself, so the names work under any driver and in any document class. They are usually enough raw material for colour expressions too: once gray!20 and blue!30!black are second nature, the appetite for more names largely goes away.

• black, blue, brown, cyan, darkgray, gray, green, lightgray, lime, magenta, olive, orange, pink, purple, red, teal, violet, white, yellow

When those run out, options add more names. dvipsnames gives the 68 colours of the dvips driver — RoyalBlue, Periwinkle, BurntOrange and the rest, all defined in cmyk. svgnames gives 151 names: those of the SVG 1.1 specification plus four taken from X11. x11names gives 317 names from the X11 rgb.txt. And here the xcolor manual makes a nice admission of its own: the 151 names of svgnames denote only 141 distinct colours, because spelling variants such as Gray and Grey point at the same value. x11names likewise offers 317 names for 315 colours. Load both sets, the manual notes, and all 752 names in rgb.txt are within reach.

These names are case-sensitive. Write royalblue for RoyalBlue and the run stops with ! Package xcolor Error: Undefined color 'royalblue'. The same error appears when you forget to load the name set at all — using Periwinkle after a plain \usepackage{xcolor}, for instance. Rather than trusting your memory for what each name looks like, open the manual with texdoc xcolor: it lists every name beside a printed swatch. One boundary worth knowing: \rowcolor, \cellcolor and \rowcolors, which shade table rows and cells, belong to colortbl rather than xcolor, and the single line \usepackage[table]{xcolor} brings in both — see the page on coloured tables.

Screen colour is not print colour: the traps of paper and accessibility

For a document going to a commercial printer, a colour written in rgb will not necessarily come off the press looking like that. Offset printing can only build colour from the four cmyk inks, and that gamut is narrower than the RGB of a screen. Pass the cmyk option to xcolor and every colour in the document is converted: blue, for instance, becomes {cmyk}{1,1,0,0}. A blue that looked vivid on screen can turn up on paper as a heavy purplish navy, and that gap is not unusual. Before you send files off, either typeset once with \usepackage[cmyk]{xcolor} and check a proof, or define your colours in cmyk from the start.

A deeper trap lies one step beyond: letting colour be the only cue. Red rows mean a warning, green rows mean fine — and that design loses all of its information the moment the page is photocopied in black and white, read by someone with a colour vision deficiency, or opened on an e-ink screen. This is exactly what the web accessibility standard WCAG asks about under "Use of Color" (success criterion 1.4.1): colour must always be paired with another cue — a symbol, bold type, an explicit label. Conveniently, xcolor gives you the means to check. Write \usepackage[gray]{xcolor} and every colour is converted to the gray model (red becomes {gray}{0.3}), which simulates a black-and-white printer directly. If the document still makes sense in that state, it is not leaning on colour too hard.

% convert every colour in the document to cmyk, for offset printing
\usepackage[cmyk]{xcolor}

% convert every colour to gray: a one-word black-and-white proof
\usepackage[gray]{xcolor}