Choosing an engine/format

pdfLaTeX, XeLaTeX, LuaLaTeX, upLaTeX — which one should you use? This page is a practical decision guide for exactly that question. It opens with a recommendation, then unpacks the factors that drive the choice, and ends with a comparison table and notes for switching engines.

The quick recommendation

Before the details, here are the first picks by purpose — for most people these are enough. Recall from the “LaTeX formats” page that each name is an engine (the processing program) combined with a format (LaTeX, the command system). Below we give them by the command you actually type (pdflatex, and so on).

• Western text (English / European languages), the simplest path, maximum package compatibility → pdfLaTeX (pdflatex). It is LaTeX’s de facto standard, with the most documentation and prior art.
• You want to use the system’s OpenType fonts, handle Unicode/multilingual text, and keep things simple → XeLaTeX (xelatex). fontspec makes non-Japanese multilingual work easy.
• System fonts and Unicode plus programmable, fine-grained control and future-proofing → LuaLaTeX (lualatex). You can shape typesetting from Lua, and the LaTeX team treats it as the future standard.
• Japanese → upLaTeX (uplatex) is the mainstream, safe choice; LuaLaTeX + luatexja is the modern, Unicode-native route (but slower). The jlreq class works with either.

In a sentence: pdfLaTeX for Western text, XeLaTeX or LuaLaTeX when you need system fonts or Unicode, and upLaTeX or LuaLaTeX for Japanese. For a new project with no special requirements, starting from pdfLaTeX (Western) or upLaTeX (Japanese) is the safe bet; if you want everything unified on Unicode for the long run, LuaLaTeX is worth choosing.

The factors that drive the choice

For when the quick answer does not fit — or when you want to know why — here are the axes one by one. Most of them come back to how the engine handles fonts and character encoding.

Fonts. pdfTeX uses TeX’s traditional font model: TFM (TeX Font Metric) plus Type1/PK fonts. It cannot simply point at an ordinary font installed on your OS. XeTeX and LuaTeX differ here most sharply — they can use the TrueType / OpenType fonts already on the system directly, named through the fontspec package, e.g. \setmainfont{Times New Roman}. fontspec requires XeTeX or LuaTeX; it does not work under pdfLaTeX.

Unicode input. XeTeX and LuaTeX are Unicode-native internally and take UTF-8 source as-is. pdfTeX, too, since the 2018 LaTeX release uses UTF-8 as the default input encoding (so \usepackage[utf8]{inputenc} is no longer needed) — but internally it still maps to 8-bit font encodings (T1 and the like), so which characters work depends on your fontenc and font, and you cannot freely type arbitrary Unicode or CJK directly. For typing multilingual text and symbols without fuss, XeTeX/LuaTeX have the edge.

Package compatibility. This is the practical trap people miss. Some packages are engine-specific. fontspec and unicode-math, for instance, are XeTeX/LuaTeX-only. Conversely pstricks works under the DVI-routed pdfLaTeX and XeLaTeX but, as a rule, not under LuaLaTeX. Parts of microtype (below) also lean toward pdfTeX/LuaTeX. The incompatibility runs the other way too: source written to follow an old tutorial may not compile on a newer engine. The cardinal rule is to check which engine your template or journal class demands before anything else.

Speed. The difference is real and noticeable. The usual ordering is pdfTeX fastest, XeTeX in the middle, LuaTeX slowest. LuaTeX carries the overhead of starting a Lua VM and shaping fonts through HarfBuzz, and on large, font-heavy documents it can run more than three times slower than pdfLaTeX (on simple documents the gap is small). Over the hundreds of recompiles a real writing session involves, that adds up.

Micro-typography. The microtype package’s character protrusion and font expansion visibly lift the look of Western text. Engine differences here are large: protrusion works on all three, but font expansion is supported only on pdfTeX and LuaTeX, not XeTeX. Interword-spacing and kerning adjustments are pdfTeX-only, disabling ligatures works on pdfTeX/LuaTeX, and letterspacing works on all three. For the very best Western output, pdfLaTeX or LuaLaTeX is the safe choice.

Graphics / PDF features and programmability. Every engine imports PNG, JPEG, and PDF through graphicx, and \includegraphics behaves much the same across them (pdfLaTeX converts EPS automatically). LuaTeX’s distinctive strength is control via Lua: you can hook into typesetting passes, or read external data to build tables — things that are awkward in macros. It also pairs well with the modern package stack including fontspec and unicode-math, which is why it is called “future-proof.”

The special case of CJK / Japanese. Setting Japanese correctly — vertical writing, line-break rules (kinsoku), spacing between Japanese and Western text — needs dedicated machinery. The long-standing default is the pTeX-family engine (uplatex), which uses Japanese JFM (font metrics) and is stable and fast. The modern alternative, LuaLaTeX + luatexja, handles everything in Unicode and lets you use system fonts freely, but it is slower (as noted). The jlreq class (built on the JIS requirements for Japanese typesetting) runs under platex, uplatex, or lualatex and auto-detects the engine. The dedicated Japanese page covers the rest.

Comparison table

The four main choices, laid out along the deciding axes. The command name is the leftmost column. For microtype, protrusion and expansion are shown separately (a dash means unsupported).

Treat the table as a guide, not a verdict. pdfLaTeX, paired with \usepackage[T1]{fontenc} and a suitable Western font package, sets many European languages beautifully; and even on XeLaTeX, microtype protrusion still applies. Read it less as a binary of “can / can’t” and more as a balance of effort against polish.

Notes for switching engines

Switching engines partway can change the result even from identical source. Here are the snags people actually hit.

Font and encoding setup changes. The pdfLaTeX staples \usepackage[utf8]{inputenc} and \usepackage[T1]{fontenc} are unnecessary on XeLaTeX/LuaLaTeX and normally omitted (they are Unicode internally); you reach for fontspec and \setmainfont instead. Carrying a pdfLaTeX preamble straight over to XeLaTeX can produce warnings or font-related errors.

% pdfLaTeX 向け（旧来）/ for pdfLaTeX (traditional)
%   \usepackage[utf8]{inputenc}
%   \usepackage[T1]{fontenc}

% XeLaTeX / LuaLaTeX 向け / for XeLaTeX / LuaLaTeX
\usepackage{fontspec}
\setmainfont{TeX Gyre Termes}  % OS / TeX のフォントを名前で指定

microtype behaves differently.** The same \usepackage{microtype} yields different effects per engine — on XeLaTeX, font expansion is simply off, for example. Layout tuned under pdfLaTeX can shift slightly (line lengths, break positions) once moved to XeLaTeX.

Package availability changes. Some packages stop working (or first become available) on the target engine. PSTricks-based figures will not run if you move them to LuaLaTeX (pstricks is unsupported there); conversely fontspec and unicode-math are unavailable on pdfLaTeX. Journal and publisher templates usually assume a specific engine, so following that first is the safe move.

For Japanese, the whole CJK-font setup changes. upLaTeX (pTeX family) and LuaLaTeX + luatexja differ in both how you name Japanese fonts and how they are embedded. Expect an engine migration to bite harder for Japanese documents than for Western ones. For the concrete command equivalents, see the “Compile commands” page.