Matterhorn 21-001 · PDF/UA-1 UA1:7.11-1

Attachment names in PDF: why both F and UF are required

Embedded attachments must carry both the byte-string filename (F) and the Unicode filename (UF).

What a screen reader actually does

The attachment is announced with a mangled or missing name.

What is in the file

A PDF carries attachments in two ways. Document-level attachments, the ones in Acrobat’s Attachments panel, are listed in the /EmbeddedFiles name tree under the catalog’s /Names. Page-level ones are FileAttachment annotations, the paper-clip icons, each with an /FS entry. Both point at a file specification dictionary:

14 0 obj
<< /Type /Filespec
   /F    (budget.xlsx)                                % byte string
   /UF   <FEFF05EA05E705E605D905D1002E0078006C00730078> % "תקציב.xlsx", UTF-16
   /Desc (Approved budget, all departments)
   /EF   << /F 15 0 R >>                              % the embedded file itself
>>
endobj

/F is the original file specification string: bytes, with no declared character set. /UF, added in PDF 1.7, is a text string, which means PDFDocEncoding or UTF-16 with a byte-order mark, so any script survives. PDF/UA-1 clause 7.11 requires every embedded file’s specification to have both. The condition fires when either is missing.

What goes wrong without them

Without /UF, a viewer has only the bytes in /F and has to guess what they mean. Plain ASCII names survive the guess. Anything else does not. A Hebrew name written into /F by software that used the Windows-1255 code page, read the way PDF reads its own byte strings, turns דוח.csv into:

ãåç.csv

Something like that is what ends up in the attachments list, and what a screen reader reads aloud: three accented Latin letters and a file extension. With several attachments named like that, a user has no way to tell which is the budget and which is the minutes, short of opening each one.

Without /F, software that predates PDF 1.7 has no name at all to show.

Where it comes from

Libraries that treat the two names as separate calls. In Apache PDFBox, for example, PDComplexFileSpecification has setFile and setFileUnicode, and code that calls only the first writes /F and nothing else.

Producers older than PDF 1.7, which had no /UF to write.

How to check it free

Acrobat Pro lists the attachments: Menu → View → Show/Hide → Side panels → Attachments on Windows, View → Show/Hide → Side panels → Attachments on macOS (Open attachments in PDFs). A garbled name there is worth following up. A clean one proves nothing either way.

qpdf shows the dictionary. Write the readable form and search it for /Filespec:

qpdf --qdf --object-streams=disable report.pdf readable.pdf

Each specification should have both /F and /UF.

veraPDF, validating against PDF/UA-1, reports it under clause 7.11. Its rule is a little wider than the condition’s wording: it also rejects a /F or /UF that is present but empty, and it only looks at specifications that actually contain an embedded file (/EF).

How to fix it free

Fix the producer if you can. In code, set both names. In PDFBox, that is both setters, with the same file name.

Attach the file again in Acrobat Pro. Adobe documents adding a document-level attachment as Edit in the global bar, then in the right pane under ADD CONTENT, More → Attach file (Add attachments to PDFs), and removing a comment attachment by right-clicking it and choosing Delete (Add attachments as comments). Adobe does not document which entries Acrobat writes into the new specification, so check the result with qpdf or veraPDF.

Or add the missing key by hand. In the readable file, add /UF (budget.xlsx) next to /F. For a name outside ASCII, write it as UTF-16 hex with the FEFF byte-order mark, as in the example above. Then repair the offsets and write a normal file:

fix-qdf readable.pdf > edited.pdf
qpdf edited.pdf report-fixed.pdf

What Taggart does

The check collects every file specification in the /EmbeddedFiles name tree and every one behind a FileAttachment annotation, and reports each that lacks /F, /UF or both, with its object id:

An embedded file specification is missing /UF.

A specification behind a FileAttachment annotation is reported under 28-016 as well. The check asks whether the keys are there, as the condition is worded, so an empty /UF () passes it; veraPDF would reject that one.

The repair is embedded-file-names, marked safe, so Fix All Safe applies it. It copies whichever name exists into the one that is missing, and records the name it copied in the change log. Two limits follow from that.

If the specification has neither name, there is nothing to copy. Taggart leaves it alone and the finding stays, because a file name is not something it can work out.

If /F holds a name in a legacy code page, Taggart copies it the way PDF reads it, garbling included. The Windows-1255 example above becomes a /UF of ãåç.csv, and the change log says exactly that:

copied /F to /UF for ‘ãåç.csv’

The file then passes the check with a name nobody can read. So read the change log for any attachment whose name is not plain ASCII, and where the copied name is wrong, correct it in the source or by hand. Taggart does not guess which code page some earlier program used.

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 Add F and UF to embedded file specifications. It is mechanical, so “Fix All Safe” applies it along with the others in one pass and lists what it changed. Your original file is never modified.

Where this sits in the standards

Related conditions

• 28-016 File attachment annotations do not conform to 7.11The file specification referenced by a FileAttachment annotation must carry both /F and /UF.
• 28-004 An annotation has neither a Contents entry nor an alternative descriptionEvery non-widget annotation needs an accessible description, either in its own /Contents or in the /Alt of the structure element that encloses it.
• 28-002 An annotation is not a direct child of an Annot structure elementNon-widget, non-link annotations must sit inside an Annot structure element so they have a place in the reading order.

Other conditions in checkpoint 21

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

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.