Matterhorn 31-029 · PDF/UA-1 UA1:7.21.7-3

ToUnicode values of U+FEFF or U+FFFE: byte-order marks

BlockerCheckpoint 31: FontsWCAG 1.3.1 (A)

Byte-order marks are not characters and must not appear as mapping targets.

The condition, as the protocol states it. “One or more Unicode values specified in the ToUnicode CMap are equal to either U+FEFF or U+FFFE.”

Matterhorn Protocol 1.1, checkpoint 31, index 31-029, section UA1:7.21.7-3. Software can decide this one on its own.

Those characters extract as invisible BOMs that corrupt the surrounding text.

What is in the map

ToUnicode targets are UTF-16 in big-endian byte order, with nothing in front: <0041> is A, <00E9> is é, <D835DC00> is a surrogate pair for a mathematical letter. A byte-order mark is the two-byte signature some UTF-16 text starts with to say which byte order follows — FE FF for big-endian, FF FE for little-endian. It has no business in a target, and PDF/UA-1 clause 7.21.7 forbids U+FEFF and U+FFFE as mapping values. Condition 31-029 is a map that contains one.

It comes in two shapes:

2 beginbfchar
<41> <FEFF0041>   % U+FEFF, then A
<42> <FFFE4200>   % U+FFFE, then U+4200
endbfchar

The first is big-endian text with a BOM in front: the right character, preceded by an invisible one. The second is worse. FF FE announces little-endian, so the bytes after it are B written the wrong way round, and read as UTF-16BE they are U+4200, a Chinese ideograph.

What the user gets

We put that map on a Helvetica font and extracted the text with Poppler’s pdftotext. The A came out as U+FEFF followed by A. The B came out as U+FFFD, the replacement character Poppler substitutes for U+FFFE, followed by 䈀.

For the first shape, the text looks right when pasted, because U+FEFF is a zero-width no-break space and draws nothing. It is still there: a search for a word containing that letter fails, word boundaries can shift, and what speech output does with it depends on the screen reader. For the second, a screen reader announces an ideograph, or nothing, where the page shows a Latin letter.

Where it comes from

One way is a producer that reuses its text-string encoder for CMap targets. PDF text strings — /Title, /Alt, /ActualText — are allowed to be UTF-16, and when they are they must begin with FE FF. A ToUnicode target is a different syntax with the opposite rule. Code that writes both through one function produces <FEFF0041>.

The little-endian shape comes from encoding to “UTF-16” with a general-purpose library call rather than to UTF-16BE specifically. In Python, "A".encode("utf-16") gives FF FE 41 00 on any little-endian machine, which is every current Mac and PC: a reversed BOM and the letter backwards, exactly the second line above.

How to check it free

Look at extracted text in hex. pdftotext file.pdf - | xxd | less and search for efbb bf (U+FEFF in UTF-8) or efbf bd (the replacement character, which is how Poppler writes U+FFFE). Unexpected CJK characters in a Latin document are the other giveaway.

Read the CMap. Find the font’s /ToUnicode object in its dictionary with qpdf --show-object= and the font’s object number from pdffonts, then print it with qpdf --show-object=14 --filtered-stream-data file.pdf. Any target containing FEFF or FFFE as one of its four-digit groups is the condition.

veraPDF’s PDF/UA-1 profile tests the Unicode value of every glyph the document shows for zero, U+FEFF and U+FFFE.

Acrobat Pro’s Accessibility Checker has a Character encoding rule; Adobe’s guidance for it in Create and verify PDF accessibility is to change the font in the source and re-create the PDF, and it does not say what the rule tests. Preflight’s Options → Browse Internal PDF Structure shows the font dictionaries but not for editing, per Adobe’s advanced preflight inspections page. Adobe says some character-encoding problems cannot be repaired within Acrobat.

How to fix it free

Fix the producer, if it is yours: write targets as UTF-16BE with no BOM. In Python that is .encode("utf-16-be").

Edit the map. The fix is mechanical once you can see it. With qpdf in QDF mode (qpdf --qdf --object-streams=disable in.pdf edit.pdf), open the CMap stream, and:

for <FEFF0041>, delete the FEFF so the target is <0041>;
for <FFFE4200>, delete the FFFE and swap each remaining pair of bytes, so 4200 becomes 0042.

Then fix-qdf edit.pdf out.pdf. Nothing on the page changes, because the CMap is only used for reading text.

Or re-export from the source with a different tool.

What Taggart does

Taggart parses every target in the map, bfchar and bfrange alike, as a sequence of UTF-16 code units, and counts the units that are FEFF or FFFE wherever they fall. One finding per font:

The ToUnicode CMap of /Helvetica maps 2 code(s) to U+FEFF or U+FFFE. Byte order marks are not characters.

The repair is tounicode-repair, the same one that handles 31-028. It is proposed rather than applied in bulk, and it does one of three things:

Rebuilds the map from the font’s encoding, when that is WinAnsiEncoding or MacRomanEncoding. The new map replaces the old one, so every BOM goes with it. On our test file this cleared the finding.
Takes characters from the document’s own /ActualText, where a span around a single glyph says what that code is and every such span agrees.
Refuses where neither applies — a composite font with no /ActualText, for example — with cannot recover a Unicode mapping, and the finding stays.

It does not do the mechanical edit described above. Stripping a BOM from a target is safe and the result is obvious, but the repair is built to write maps from evidence in the file, and does not special-case this.

How Taggart handles it

Taggart checks for this condition automatically and reports it as a blocker, with where in the file it found it.

The fix is Repair ToUnicode CMaps. It changes what the document means, so Taggart proposes it and waits for your approval rather than applying it unattended.

Whatever Taggart changes, the page still looks identical. Fixes edit the PDF object model, not the content streams, and every remediation is re-rendered and compared against the original at structural similarity ≥ 0.999 before you get the file back. A tool that quietly reflows your document is worse than no tool.

Frequently asked questions

Why is a BOM wrong here when PDF text strings start with one?

Because they are different syntaxes. A PDF text string encoded in UTF-16 has to begin with FE FF to say so. A ToUnicode target is defined as UTF-16BE already, so the same two bytes are read as a character, U+FEFF, in front of the real one.

Will a screen reader say anything?

For U+FEFF, probably not: it is an invisible zero-width character, and whether speech skips it depends on the screen reader. Search, word boundaries and anything that compares text do not skip it. U+FFFE is not a character at all, and when it marks little-endian bytes the character after it is wrong too.

Does Taggart find a BOM in the middle of a target?

Yes. It reads every target as a sequence of UTF-16 code units and counts any unit that is FEFF or FFFE, wherever it falls in the target.

Where this sits in the standards

Standards this condition maps to
Standard	Reference
Matterhorn Protocol 1.1	Checkpoint 31 (Fonts), index 31-029
PDF/UA-1 (ISO 14289-1)	Clause 7.21.7-3
WCAG 2.1	1.3.1 Info and Relationships — Level A
EN 301 549 / Section 508 / ADA Title II	All three point at WCAG 2.1 Level AA for non-web documents, so a Level A or AA criterion here is in scope for each of them.

Other conditions in checkpoint 31

Checkpoint 31 covers fonts. These are its other failure conditions; the ones without a link are in the rule set but do not have a written page yet.

Check your own file. Taggart’s validator is free and unlimited — 75 of the 87 Matterhorn conditions software can decide, with the other 12 listed for you to confirm; no watermark, no expiry, and no account needed up to 60 pages.

Check a PDF free

Checked with Taggart on a generated file that fails this condition on 2026-10-02. The Acrobat steps follow Adobe’s documentation and were not walked through by hand. Last updated 2026-10-02.