PDF String
A PDF string is one of the eight basic object types in PDF. Strings are arbitrary sequences of bytes — they can represent text characters, binary data, dates, names (in certain contexts), and encoded values. Unlike programming languages where strings have a single universal representation, PDF strings come in two syntaxes (literal and hexadecimal) and can be encoded in multiple ways depending on their context and content.
Understanding PDF strings is essential for correctly reading and writing PDF metadata, annotations, form field values, and any other PDF data that contains human-readable text — because the relationship between the bytes stored in a PDF string and the characters they represent is not always obvious.
Literal strings and hexadecimal strings
<strong>Literal strings</strong> are enclosed in parentheses: <code>(Hello World)</code>. Within a literal string: - Parentheses must be balanced or escaped with a backslash: <code>(text \(with parens\))</code> - Backslash introduces escape sequences: <code>\n</code> (newline), <code>\r</code> (return), <code>\t</code> (tab), <code>\\</code> (backslash) - <code>\ddd</code> encodes a byte as a 1–3 digit octal value: <code>\101</code> = byte 0x41 = 'A' - A newline preceded by a backslash is a line continuation (the newline is ignored)
<strong>Hexadecimal strings</strong> are enclosed in angle brackets: <code><48656C6C6F></code>. Each pair of hex digits represents one byte. Spaces are allowed between hex pairs. An odd number of hex digits is valid — the last digit is treated as if followed by a zero. <code><9></code> = byte 0x90.
Both forms represent identical data — they are syntactic alternatives for writing the same string value. Hexadecimal strings are typically used when the byte values are not printable ASCII (binary data, UTF-16 strings with null bytes) or when clarity is important for binary content. Most text strings in PDFs appear as literal strings when they contain only ASCII characters.
<strong>String as a primitive type</strong> — Strings can appear as the value of any PDF dictionary entry. The /Title entry in the document information dictionary is a string; the /T field name in a form field is a string; the /Contents annotation text is a string; the PDF date format is a string (<code>(D:20240101120000+00'00')</code>).
Text strings: PDFDocEncoding and UTF-16BE
A key distinction exists between PDF strings used for <em>text</em> (human-readable character sequences) and PDF strings used for <em>binary data</em> (byte sequences without Unicode meaning):
<strong>PDFDocEncoding</strong> — A PDF-specific single-byte encoding covering Latin characters. PDFDocEncoding maps byte values 0x18–0x7E and 0xA0–0xFF to Unicode characters (similar to ISO 8859-1 but with differences in the 0x80–0x9F range). A text string without a BOM is assumed to be PDFDocEncoding. This encoding handles most Western European languages but cannot represent CJK characters, Arabic, Hebrew, or other non-Latin scripts.
<strong>UTF-16BE with BOM</strong> — For text strings requiring characters outside PDFDocEncoding, PDF uses UTF-16 big-endian encoding. The string must start with the UTF-16 BOM (Byte Order Mark): the two bytes 0xFE 0xFF. A UTF-16BE string looks like: <code><FEFF00480065006C006C006F></code> — BOM followed by 'H', 'e', 'l', 'l', 'o' in UTF-16BE (2 bytes per character).
<strong>UTF-8 (PDF 2.0)</strong> — PDF 2.0 introduced UTF-8 as a third option for text strings. A UTF-8 string starts with the UTF-8 BOM: the three bytes 0xEF 0xBB 0xBF. This simplifies string handling in modern PDF generators.
<strong>Detecting the encoding</strong> — PDF processors check the first bytes: - Starts with 0xFE 0xFF → UTF-16BE (strip BOM, decode UTF-16BE) - Starts with 0xFF 0xFE → UTF-16LE (strip BOM, decode UTF-16LE — rare in PDF) - Starts with 0xEF 0xBB 0xBF → UTF-8 (PDF 2.0, strip BOM, decode UTF-8) - Otherwise → PDFDocEncoding
Strings in annotations, metadata, and form fields
<strong>Annotation text</strong> — The /Contents entry of annotations (text notes, comments, highlights) is a text string. If the annotation contains characters outside Latin-1, the /Contents string must use UTF-16BE with BOM. PDF viewers display this string as the annotation's text content.
<strong>Document Information Dictionary</strong> — The /Title, /Author, /Subject, /Keywords, /Creator, /Producer entries are all text strings. Historically many were PDFDocEncoding; documents with non-ASCII author names or titles may use UTF-16BE. This is why non-ASCII characters in PDF metadata (author names with accents, Japanese titles) sometimes appear garbled in viewers that do not correctly detect the encoding.
<strong>Form field values</strong> — AcroForm field values (/V entry) are strings. Text field values are text strings (PDFDocEncoding or UTF-16BE). Signature field values (/V) are strings containing the binary DER-encoded signature blob — a hexadecimal string is typical.
<strong>Date strings</strong> — PDF dates follow the format <code>(D:YYYYMMDDHHmmSSZ)</code> where Z is the timezone offset (<code>+HH'mm'</code> or <code>Z</code> for UTC). Example: <code>(D:20240101120000+00'00')</code> = January 1, 2024 at 12:00 UTC. Dates are stored as ASCII literal strings — no encoding issues.
<strong>Encryption of strings</strong> — When a PDF is encrypted, text strings (and stream data) are encrypted using the document's encryption key, with a key derived from the object number and generation number. Not all strings are encrypted: the /Encrypt dictionary itself, the /ID array, and certain other strings are exempt. See <a href="/glossary/pdf-encryption" target="_blank" rel="noopener">PDF Encryption</a> for encryption details.
Frequently asked questions
Why does PDF metadata show garbled characters for non-English names?
Garbled metadata characters almost always indicate an encoding mismatch: the PDF generator used one encoding for the string, and the PDF viewer decoded it with a different assumption. Common scenarios: (1) A PDF generator wrote a PDFDocEncoding string but used the system's code page (e.g., Windows-1252 or Windows-1250) instead of the actual PDFDocEncoding — subtle differences in the 0x80–0x9F range cause incorrect characters. (2) The viewer assumed PDFDocEncoding but the string was UTF-16BE without a BOM. (3) The XMP metadata (the other place PDF stores title/author) uses UTF-8 and is correct, but the viewer is reading the Info dictionary string which is incorrectly encoded. Fix: regenerate the PDF metadata with a tool that correctly handles UTF-16BE for non-ASCII characters, or update the metadata using ExifTool or a PDF processor with correct encoding support.
Are PDF strings the same as PDF names?
No. PDF names and PDF strings are different object types. A PDF name (written with a leading slash, e.g., /Type, /Page, /FlateDecode) is an atomic identifier — essentially a symbol. Names are used as dictionary keys and as identifiers for resources, filter types, and operators. Names can contain any character except delimiters and whitespace, with non-printing characters encoded as #xx hex escapes. A PDF string (written in parentheses or angle brackets) is an arbitrary byte sequence that can represent text, binary data, or encoded values. Strings are used as dictionary values for text content. The distinction matters: /Helvetica is a name (a font name); (Helvetica) would be a string (though strings are not used for font names in practice).
How do I inspect string values in a PDF?
Several tools expose PDF string values: (1) qpdf --qdf mode produces a human-readable "QDF" file showing all strings in their ASCII or hex form — useful for reading metadata and annotation text. (2) PyMuPDF: doc.metadata returns a dictionary of decoded metadata strings; annot.info["content"] returns annotation text. (3) pdfinfo (Poppler command-line): shows document info strings including title, author, dates. (4) ExifTool: exiftool -pdf:all document.pdf extracts all Info dictionary strings with proper encoding handling. (5) RUPS (an open-source PDF object inspector): shows raw PDF objects including string values in their encoded form.