2026-09-07

It opened fine on my computer — why your PDF looks different, or blank, on the recipient's screen

Nearly every PDF complaint that reaches a help desk is a complaint about the second screen. The file opened perfectly on the machine that made it. Then somebody else opened it and saw something else: text in a typeface nobody chose, with the line breaks landing in the wrong places; a form whose boxes had all gone empty; a page that simply refused to display on a phone. The sender cannot reproduce any of it, because on their machine it still looks exactly right.

This post is about that second screen. Not how to assemble a submission — that ground is covered elsewhere on this blog — but what actually travels inside a PDF when you send one, which parts of it quietly depend on software the recipient may not have, and the checks worth two minutes before you hit send. NearPDF's role here is small and mostly cautionary, and this post says so plainly, including one job you should specifically not hand it.

Somebody has already written the list down

You do not have to guess at what breaks on the far end, because at least one large recipient publishes its rejection criteria. The Administrative Office of the U.S. Courts' guide PDF-Related Functionality for Public Filers in NextGen CM/ECF (Release 1.6, November 2020) opens with the familiar promise — the format "allows anyone to open the converted document across a broad range of hardware and software with the layout, format, links, and images intact" — and then spends a page enumerating the cases where that promise fails badly enough that the court's own system will refuse the file. PDFs are rejected if the file "does not comply with PDF format standards," "contains JavaScript," is "encrypted or password-protected," "contains internal attachments," or "contains audio and video content."

Two entries on that reject list are worth reading twice, because they are not about content at all. A PDF is rejected if it was "created with Mac OS X using a fillable form in the Safari browser," and rejected if it was "created with Mac OS X using MS Word and selecting the option, 'Best for printing'." Meanwhile the accept list includes a PDF "created with Mac OS X using a fillable form in the Chrome browser," and one made in Word with "Best for Electronic Distribution." Same person, same form, same afternoon — and whether the file is usable on the other end is decided by which browser was open and which radio button was selected in a print dialog. Nothing on your screen distinguishes the two. This is the whole problem in miniature: a PDF is not one thing, it is a container, and what got put in the container depends on the program that filled it.

The blank form, and the two places a filled value can live

The most common version of this on the receiving end is the form that arrives empty. You typed into every box, saved, attached, sent — and the reply says the fields are blank.

The reason is that a filled form field stores its answer in two different places, and viewers disagree about which one to trust. There is the value itself, held in the field dictionary, and there is a small drawing program — an appearance stream — that paints that value inside the box. A well-behaved filler writes both. A lazier one writes only the value and sets a flag called NeedAppearances, which is a request to the reader: you draw this. Readers that honour the flag show your text. Readers that ignore it show an empty box, faithfully rendering a field that was never actually drawn.

Korea's national archiving standard treats this as serious enough to legislate away. NAK 30:2022, the National Archives of Korea's technical specification for the document-type preservation format (a PDF/A-1b profile, issued under the Public Records Management Act), devotes its section 6.9 to interactive forms and states the goal outright: the conditions exist "to guarantee that there is no ambiguity in the presentation of form fields." Its rules follow directly from the failure above — the interactive form dictionary's NeedAppearances flag "shall be absent or its value shall be false," and "every form field shall have an appearance dictionary associated with the field data," with a conforming reader rendering the field "according to the appearance dictionary, regardless of the form data." Translated out of standards prose: a document you are going to hand to someone else must carry the picture, not just the data, because you cannot assume their reader will draw it for you.

This is why every U.S. federal court that publishes filing guidance says the same thing about fillable forms. The Fifth Circuit's How to Flatten PDF Forms is one sentence long on the why: "When using a PDF fillable form, the user must lock or 'flatten' the PDF document after completing the form fields to ensure the document can be viewed on all devices and to prevent other users from manipulating or editing the information." The Arizona bankruptcy court's version repeats it word for word and adds the mechanism — flattening "will prevent any user from saving the document and editing the form fields." Both give the same recipe, and it is deliberately dumb: open the filled form, File, Print, choose a PDF printer, save the printed copy. Printing re-draws the page, so whatever was on screen becomes ordinary page content with no fields left to disagree about.

The form that will not open at all

A smaller but nastier category is the form that shows the recipient a message instead of a document. The Nebraska Department of Education publishes the exact text its own form users hit: "Please wait… If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document." That is not a loading message that failed. It is a cover page, deliberately placed inside the file, shown to any reader that cannot handle what is behind it — an XFA form, an XML form description wrapped in a PDF shell.

Microsoft's own administrator documentation for the Edge policy ViewXFAPDFInIEModeAllowedOrigins is unusually blunt about the state of this technology: "XFA is a legacy technology that's deprecated by its original creators. It's not an ISO standard and as such doesn't align with the modern web architecture. Continued use poses potential risks and vulnerabilities." Microsoft's workaround is to reopen such files through Internet Explorer mode using an Acrobat ActiveX plugin that the policy does not install, and the platform table underneath tells you how narrow that escape hatch is: Windows version 132 or later, and macOS, Android and iOS all listed as "Not supported." So if the form you forwarded is XFA, your recipient's phone is not going to open it, and neither is their Mac. Microsoft's advice is to migrate off it entirely.

Nothing NearPDF does can repair an XFA form, and it will not pretend otherwise — such a file either loads as a nearly-empty shell or fails to parse. The useful move is upstream: fill it in Acrobat Reader on a desktop, print it to PDF, and send the printed copy. What comes out the other side is a plain page that every reader on earth can draw.

Why the letters move

The subtler failure is the one where everything opens but nothing sits where you left it. Headings wrap onto a second line, a table drifts a column wide, and the whole document looks like a slightly worse version of itself. That is font substitution: the file referred to a typeface by name without carrying the typeface, and the recipient's reader supplied the nearest thing it had. Different metrics, different widths, different line breaks.

NAK 30:2022 spells out the fix as a hard requirement in its section 6.3.4 on embedded font programs: the font programs of every font used in a conforming file "shall be embedded in the file," only fonts that may lawfully be embedded without restriction and with full rendering may be used, and every conforming reader "shall use the fonts embedded in the file for rendering, rather than fonts that are locally resident, substituted or simulated." Section 6.3.1 says why in one line — the point of the conditions is to guarantee that the shape of the characters matches how they were originally produced.

Whether that actually happens is decided in the dialog you clicked past. Hancom's official help page for Save as PDF in Hancom Office puts three of these traps on one screen, and they are worth knowing even if you never touch the suite, because equivalents exist in every office program. It notes that a document containing OTF fonts will have those fonts "replaced by other fonts" in the converted PDF; that only fonts whose vendor has granted embedding permission can be embedded at all, and that when a font is embedded "the font is not substituted when the user views or prints the file, and the text appears in its original font"; and — a separate trap entirely — that a document set to a custom paper size is converted at the default A4 size, so "some content of the original document that falls outside the area may not appear correctly." A custom-sized certificate or drawing can therefore lose its edges on the way into a PDF, before any recipient is involved.

The two-minute check

All of this collapses into a habit that costs almost nothing. Before you send a file that matters, open it a second time in a viewer that is not the one that made it — if you exported from Word or Hancom, look at it in a browser; if you filled a form in a browser, look at it in a desktop reader. Then open it on your phone. Those two views cover most of the failure modes above, because they are exactly the readers that will not paper over your file's assumptions. Look for three things: are the filled fields still filled, is the typeface the one you chose, and does the last line of each page still fit on the page.

If the file is a form you filled in, flatten it before it goes anywhere, using the print-to-PDF recipe the courts publish. If the file has to survive being archived, or you simply want the strongest guarantee available, export it as PDF/A rather than plain PDF — that is the switch that forces font embedding and forbids encryption in the first place. Most office suites offer it in the same save dialog; Hancom's help page notes its PDF export writes PDF/A-1b by default.

Where NearPDF fits, and one thing not to use it for

NearPDF is a page-level tool. It merges, splits, reorders, rotates, deletes pages, stamps page numbers and watermarks, and converts pages to JPG — all inside your browser, with the file never leaving your device. Against the problems in this post it does three modest things and one dangerous-looking thing that is worth spelling out.

First, it is a usable canary for encryption. If a contributor sends you a password-protected PDF, NearPDF cannot open it and says so by name — "is password-protected and was skipped" — rather than silently dropping it. That is the same category CM/ECF rejects outright and that the Korean archiving profile forbids by banning the Encrypt keyword from the file trailer, an explicit prohibition the standard notes has the implicit effect of forbidding encryption and password-protected access permissions. A file NearPDF refuses is a file that will probably give your recipient trouble too. The reverse does not hold: NearPDF opening a file proves nothing about whether a court's or an agency's intake system will accept it.

Second, when a recipient genuinely cannot render your PDF at all, the PDF-to-JPG tool turns the pages into images that any device can display. Treat it as a last resort and understand the trade: the result is pictures. Nobody can select the text, search it, or copy a figure out of it, and no intake system that expects a PDF will take it.

Third — and this is the one to be careful about — do not run a fillable form through NearPDF and assume you have flattened it. NearPDF rebuilds output by copying the pages you kept into a fresh document (pdf-lib's copyPages, in src/merge.worker.js). Running pdf-lib 1.17.1, the exact version this app ships, against a filled form and inspecting the result shows precisely what that does: the catalog's AcroForm entry is gone, so the file is no longer a form and form tooling reports zero fields in it. But the widget annotation is still on the page carrying a byte-identical appearance stream, so the typed text still draws — and the field dictionary it points at still holds the value you typed. So the output looks flattened and reports as fieldless while your answer is still sitting in the file. That is the worst of both worlds: you lose the form, you do not lose the data, and a fields check gives you a false all-clear. Flatten with print-to-PDF, the way the courts describe, and only then bring the result to NearPDF if you need pages combined or reordered.

The honest limits

NearPDF cannot embed a font, because it never adds text of its own except the page-number and watermark stamps, and those use Helvetica — one of the fourteen base fonts every reader has built in, which is exactly why they cost nothing to ship and exactly why they cover Latin script only. Type a Korean, Japanese, Chinese, Cyrillic, Arabic or Thai watermark and the tool names the characters it cannot draw and refuses, before processing anything, rather than producing a page of blanks. It has no OCR, so a scan stays a picture of text. It has no compression: the only way it makes a file smaller is by removing pages. It generates no bookmarks or outline. Deleting pages rebuilds the file from the pages you kept, so a removed page is genuinely absent rather than hidden — but that is page-level removal, not redaction, and as the form finding above shows, "the tool no longer reports it" is not the same as "it is no longer in the file." It takes PDFs only, up to 500 MB on a normal desktop, or 50 MB per file and 100 MB in total on phones and low-memory machines. And it cannot open an encrypted file at all.

None of which is the point of this post. The point is that the file you are about to send is a container of assumptions, most of which you can check in two minutes on a second screen, and one of which — the filled form — has a fix that federal courts have been publishing, unchanged, for years.