Undefined control sequence

! Undefined control sequence is the first LaTeX error almost everyone meets, and strictly speaking it is not a LaTeX error at all: plain TeX prints exactly those three words with no LaTeX loaded. Control sequence is TeX’s own name for a backslash followed by a name, and the message says only that the name is not in its dictionary. What makes it the most-searched error of the lot is what happens next — TeX does not stop. It silently discards the unknown command, reads on, and hands you a PDF in which the command’s arguments have turned into ordinary body text. This page covers the three causes that account for nearly every case — a misspelling, a package that was never loaded, and a macro used before it existed — and the trap that the line number in the log is where TeX noticed, not always where the mistake is.

Reading the message: the break in the line is the culprit

The command at the end of the upper of the two lines is the undefined one. When TeX reports an error it splits the offending line into what it has already read and what it has not read yet, stacking the two halves. It stopped reading at the moment the trouble happened, so the break itself points at the culprit. Below is real log output from \textbf mistyped as \textbnf.

! Undefined control sequence.
l.4 This is \textbnf
                    {bold} text.

l.4 means line 4. When the trouble happens inside math, a line such as <recently read> \fra may appear above l.4, naming the command on its own. Either way the first move is to search your source for that command name. If the spelling is right, move on to the next section. Note that mistyping the package name gives a different error entirely: ! LaTeX Error: File followed by the name of the missing .sty.

Only three things cause it: spelling, packages, order of definition

In practice the causes come down to just three: a misspelling, a package you forgot to load, and a macro used before its definition. The order matters too — work down the list, because checking spelling takes seconds, checking the preamble takes a glance, and only the macro case takes real work.

• A misspelling — \fra for \frac, \textbnf for \textbf, \begni for \begin. Command names are case-sensitive, so \Latex for \LaTeX is undefined too.
• A package never loaded — the spelling is right, but the package that defines the command was never given to \usepackage in the preamble. See the table in the next section.
• A macro used before its definition — a forgotten \newcommand, a use above the line that defines it, or a definition sitting inside braces or an environment so that it vanishes outside them.

Which package defines the command?

The table below pairs the commands most often undefined for this reason with the package that defines them (checked with \ifdefined on TeX Live 2024). The most common mix-up is amsmath versus amssymb. \lVert lives in amsmath and not in amssymb; \mathbb and \therefore live in amssymb and not in amsmath. If a math command is undefined even though "the package is loaded", suspect this first. For anything not in the table, texdoc PACKAGE opens that package’s manual.

The \newcommand that did not take: order and scope

TeX reads top to bottom, once, so the definition has to come before the use. People look at a source file as a whole; TeX reads it line by line and only enters a name in its dictionary the moment it reaches the \newcommand. Define a macro on line 200 and use it on line 40 and it is undefined. The other trap is scope: a macro defined inside braces or an environment disappears at the closing brace. Both accidents go away if the definitions live in the preamble. The mechanics of \newcommand itself — arguments, defaults, how it differs from \renewcommand — belong to the "Defining macros" page.

\documentclass{article}
\begin{document}
% too early: \R is not in the dictionary yet
$\R$
\newcommand{\R}{\mathbb{R}}

% scoped: \tmp dies at the closing brace
{\newcommand{\tmp}{scoped}\tmp}
\tmp
\end{document}

When the reported line is not where the mistake is

If a line containing -> appears above l.NN, the mistake is inside the macro named on that line. l.NN is only where TeX noticed — that is, the line where the macro was used. The definition itself may be hundreds of lines away, or inside a package. In the example below \mysq calls \mynorm, which uses \lVert, and amsmath was never loaded. The log line \mynorm #1->\lVert is the only clue you get.

! Undefined control sequence.
\mynorm #1->\lVert
                   #1 \rVert
l.5 The value $\mysq{x}
                       $ is here.

Notice that \mysq is not named in that log at all. LaTeX sets \errorcontextlines to -1 (line 535 of latex.ltx), so only the innermost frame of the macro call chain is shown. That is not enough when the failure is inside a package. Put \errorcontextlines=999 in the preamble and recompile: a line \mysq #1->\mynorm {#1} appears and the whole call path becomes visible. Take it out once you have the answer — a quiet log is easier to read day to day.

It still produces a PDF, and that is the real danger

An undefined command does not stop the typesetting. TeX throws away that one command and sets the rest as ordinary characters. Forget graphicx and write \includegraphics[width=3cm]{example-image}, and you get not just a missing image but a PDF with the options and the filename printed as body text. Editors and build tools run with -interaction=nonstopmode by default, so the run sails past the errors and produces a file — which is exactly how a broken PDF gets submitted. If even one undefined command is left in the log, do not trust the PDF.

% graphicx was never loaded
\includegraphics[width=3cm]{example-image}

% the run still succeeds, and this is what lands on the page:
%   [width=3cm]example-image