PDF CMap (Character Map)
A CMap (character map) in PDF is a mapping table that converts character codes in a string to character identifiers (CIDs) or Unicode code points. CMaps are used in Type 0 (composite) fonts to support large character sets such as CJK scripts, and in /ToUnicode entries to enable reliable text extraction and copy-paste.
A CMap (Character Map) is a PDF data structure that maps character codes to character identifiers (CIDs) or to Unicode values. CMaps are the mechanism by which PDF fonts translate the raw byte sequences in a content stream into the characters they represent — they are essential for text extraction, copy-paste, search, and accessibility in PDF documents.
PDF uses two types of CMaps in different ways: encoding CMaps (mapping character codes to CIDs within a composite font) and ToUnicode CMaps (mapping character codes to Unicode codepoints for text extraction purposes). A PDF without ToUnicode CMaps may render correctly but be completely unsearchable and uncopiable.
CMap types and structure
CMaps in PDF come in two varieties:
<strong>Encoding CMaps</strong> — Used by Type 0 (composite) fonts to map multi-byte character codes to CIDs. Composite fonts use CIDFont dictionaries which store character outlines indexed by CID number. The CMap sits between the raw bytes in the content stream and the CIDFont, translating codes to CIDs. CMaps for CJK fonts often reference predefined CMaps maintained by Adobe — stored in the PDF viewer's CMap resources rather than embedded in every document. Examples include Identity-H and Identity-V (which map 2-byte codes directly to CIDs, used for horizontally and vertically written text respectively).
<strong>ToUnicode CMaps</strong> — Embedded in any font dictionary (not just composite fonts) as the /ToUnicode stream entry. These map the same character codes used in the content stream to Unicode codepoints (expressed as hex: <code><0041></code> for U+0041 "A"). ToUnicode CMaps enable text extraction, copy-paste from the PDF, and are required for PDF/UA accessibility compliance. Without a ToUnicode CMap, a text extraction tool cannot determine what character a glyph represents.
A CMap stream contains <code>beginbfchar</code>/<code>endbfchar</code> blocks (single-character mappings) and <code>beginbfrange</code>/<code>endbfrange</code> blocks (range mappings). For example: <code>2 beginbfchar</code> <code> <01> <0041> % code 1 → Unicode U+0041 "A"</code> <code> <02> <0042> % code 2 → Unicode U+0042 "B"</code> <code>endbfchar</code>
Identity-H and Identity-V
Identity-H and Identity-V are predefined CMaps used with CIDFonts for CJK (Chinese, Japanese, Korean) text. Instead of mapping character codes to CIDs via a lookup table, Identity-H maps 2-byte character codes directly to the same 2-byte CID (identity mapping). This is widely used with TrueType CIDFonts for CJK scripts because Unicode codepoints can serve directly as CIDs when the font's cmap table maps Unicode to glyph IDs.
Identity-H indicates horizontal writing mode; Identity-V indicates vertical writing mode. PDF/A-2 and later require that all fonts using Identity-H or Identity-V have a ToUnicode CMap — because the identity mapping alone does not provide Unicode values for text extraction.
The "H" and "V" suffix refers to writing direction, not encoding: both are 2-byte identity CMaps, differing only in the direction metadata they encode. See <a href="/glossary/pdf-truetype-font" target="_blank" rel="noopener">PDF TrueType Font</a> for how TrueType CIDFonts use Identity-H to embed CJK text.
CMaps and text extraction failures
Missing or incorrect CMaps are the most common cause of garbled text extraction from PDFs. Common scenarios:
<strong>Missing ToUnicode CMap</strong> — The PDF renders correctly (shapes are mapped to glyphs correctly), but text extraction tools cannot determine the Unicode values. The extracted text may be empty, may show incorrect characters, or may show CID numbers instead of characters.
<strong>Wrong ToUnicode mapping</strong> — Some PDF generators produce ToUnicode CMaps that map codes to incorrect Unicode values (common with custom symbol fonts or proprietary CJK encodings). The PDF renders correctly but copy-paste produces garbage.
<strong>Ligature and composite glyph mappings</strong> — Some fonts use ligature glyphs (a single glyph representing "fi", "fl", "ff") with a single character code. If the ToUnicode CMap maps the ligature code to a single Unicode character (e.g., mapping the "fi" ligature to only "f"), extraction loses characters. Correct ToUnicode mappings for ligatures use multi-character mappings: <code><XX> <00660069></code> (mapping one code to U+0066 U+0069 "fi").
<strong>ActualText as an alternative</strong> — For tagged PDFs, the /ActualText attribute on span elements can provide the Unicode text for glyphs even when the ToUnicode CMap is missing or incorrect. PDF/UA requires this for any glyphs whose Unicode representation cannot be derived from the ToUnicode CMap alone. See <a href="/glossary/tagged-pdf" target="_blank" rel="noopener">Tagged PDF</a> for ActualText usage.
Frequently asked questions
Why does copy-pasting text from a PDF produce garbled characters?
Garbled copy-paste almost always means the font's ToUnicode CMap is missing, incomplete, or incorrect. The PDF viewer renders the glyphs correctly (using the font's encoding), but when you copy text, the viewer needs the ToUnicode CMap to translate character codes to Unicode characters for the clipboard. If the CMap maps codes to wrong Unicode values — or if there is no ToUnicode CMap at all — the clipboard receives incorrect characters. This is common with PDFs exported from older design tools, PDFs using custom symbol fonts, or PDFs from software that treats text as graphics. Rebuilding the PDF with a PDF export tool that correctly generates ToUnicode CMaps usually fixes the problem.
What is the difference between CMap and font encoding in PDF?
Font encoding (the /Encoding entry in a simple font dictionary) maps single-byte character codes (0–255) to glyph names, which are then resolved to glyph outlines via the font's CharStrings or glyph table. This is the mechanism for simple (non-composite) fonts like Type 1 and TrueType with single-byte encoding. A CMap (used with Type 0 composite fonts) is a more general mechanism that supports multi-byte character codes and maps directly to CIDs rather than glyph names — necessary for the thousands of characters in CJK character sets. The /ToUnicode entry is a separate stream (formatted as a CMap) added to any font (simple or composite) to enable text extraction. These three mechanisms serve related but distinct purposes: encoding controls rendering; ToUnicode enables extraction.
Are CMaps required in PDF/A documents?
Yes. PDF/A-1 requires that all fonts have sufficient information to extract the Unicode text for every rendered character — in practice, this means ToUnicode CMaps for most fonts, or use of standard Latin encodings where the Unicode mapping is implicit. PDF/A-2 and later tightened this requirement: fonts using Identity-H or Identity-V CMaps must have a ToUnicode CMap. PDF/UA additionally requires that every character have a deterministic Unicode mapping, either through ToUnicode or through ActualText attributes on tagged content. Validation tools like veraPDF report ToUnicode failures as errors in PDF/A and PDF/UA validation.