PDF or HTML for the documents you publish: five checks you can explain to a client

“Just put this document up as a PDF.”

An agency director using MONJI+ told us this is how it usually arrives. The client hands it over, and with nothing solid to push back with, it goes up as-is.

What struck us first was how familiar that sounded.
Dropping in a PDF and linking to it is fast, and it feels like work got done. There’s even a small hit of satisfaction the moment it goes live. Looking back, that feeling was the problem: we thought we were finished. What actually matters isn’t whether it’s published. It’s whether the person looking for that information can get to it.

This article turns the PDF-or-HTML call into a procedure you can apply on the spot.

PDF or HTML isn’t a matter of taste. It’s a question of whether readers can reach the information. Japan’s Digital Agency, in its own accessibility test results, states plainly that where there’s no real need for a PDF, a web page should be provided. The call doesn’t have to be a gut feeling: five checks will settle it.

• A PDF needs assistive-technology information added after the fact. Straight out of the export, it often can’t be read properly.




• If you need it found in search, updated over time, or quoted in part, HTML is the better fit.




• This isn’t a ban on PDFs. It’s an order of operations: ask whether the PDF is necessary first.

Why “just PDF it” keeps winning

Let’s name the wall first.

Documents keep going up as PDFs not because anyone is careless, but because there’s nothing solid to push back with.

Say only “PDFs are bad for accessibility” and the room usually goes stiff. You think you explained it, they think they heard it, and it still comes back to “so why can’t we use a PDF?” We’ve had that exchange more than once. And we were usually the ones explaining it badly.

There’s a second reason: the problems with a PDF don’t show up visually. A file that looks perfectly fine on screen can, through assistive technology, jump around out of order or read a table out as a flat run of characters. The person who made it won’t catch it by looking. Looking finished and being readable are two different things.

So the blocker is a missing source and a missing set of criteria. Start there.

The source you can lean on

Before the steps, the evidence.

Japan’s Digital Agency published the accessibility test results for its own site on March 31, 2026. The scope was every page under digital.go.jp. What they actually tested was 17 representative web pages and one PDF, plus 30 randomly selected web pages and nine PDFs.

One line in the improvement plan stands out.

Where there is no real need for a PDF, provide a web page.

They wrote that as the policy for their own site. It isn’t a ban on PDFs. It sets an order: ask whether the PDF is necessary first. That order is what you can use directly on real projects.

The PDF problems from the same testing weren’t vague warnings either. They were specific:

• No tagging, no language setting, no file title




• Not enough structure for alt text, headings, tables, and lists




• No reading order set

A PDF exported straight from a word processor tends to land in exactly this state.

Source: Japan’s Digital Agency, web accessibility test results (2025) https://www.digital.go.jp/accessibility-statement/test-result-2025

Source: W3C, PDF Techniques for WCAG 2.0 https://www.w3.org/TR/WCAG20-TECHS/pdf

Four steps to decide the format

This is the order we work through between receiving a document and publishing it.

STEP 1: Run the five checks for HTML

If even one of these five is true, HTML is the better fit.

1. You want it found through search. PDFs do get indexed, but pointing someone at one specific part of the document is hard.




2. The content will be updated. Rebuilding the file every time it changes is how updates quietly stop happening.




3. People will read it on a phone. A PDF is built to a paper size, so a small screen means zooming and scrolling sideways.




4. You want parts of it quoted or copied. Anything handled as text takes fewer steps on the reader’s side.




5. Someone using a screen reader may read it. HTML carries heading and table structure natively.

STEP 2: Check whether PDF is genuinely the right fit

A PDF is the better fit when:

• The document is meant to be printed and handed out.




• It’s a drawing or a form where a broken layout changes the meaning.




• It needs to be preserved without alteration.

When you’re torn, ask whether you can picture the document being handed out on paper. Distributed at a venue. Printed and passed around. Signed or stamped. If any of those come to mind, the PDF is earning its place.

If nobody prints it, it gets updated, and people read it on their phones, then “let’s just PDF it” is probably us taking the easy road. Us included.

STEP 3: If it stays a PDF, fix four things before publishing

Even with a genuine need, work remains. Check these four at minimum.

1. Set the file title. Not the filename. The title in the document properties.




2. Set the language. If it isn’t recognized as the language it’s written in, screen readers get awkward.




3. Add structure for headings, tables, and lists. Using styles correctly in the source file cuts the work later.




4. Add alt text to figures. Check the reading order while you’re there.

Items 3 and 4 are faster to fix in the source file than in the PDF. Plan on patching them by hand after export and you’ve signed up for the same job on every update.

There’s also the option of publishing a one-page summary of the PDF’s contents. The document itself can stay a PDF, but if what’s inside is readable as HTML, you’ve built an entrance from search.

STEP 4: Put the criteria into your pre-launch checks

Keep the five checks in your head and the call varies by whoever happens to be handling it. Write them into the pre-launch review list and apply them in the same order every time. Record why you decided each way, and you won’t rerun the same debate when staff change.

MONJI+ is a WebOps platform that keeps pre-launch review and feedback requests in one place. The PDF-or-HTML checks live in a checklist you run before publishing, and the reasoning behind each call stays in the Wiki. When wording needs fixing after launch, you drop a comment on that exact spot on the page and hand it off as a feedback request.

What changed in the client conversation

The hard part on real projects isn’t the technical side. It’s the conversation. Three angles we use now:

• Make it about the reader. Say specifically that for someone using a screen reader, this PDF may be read out of order.




• Make it about being found. Say that when someone searches for this document, a PDF makes it harder to point them at the right part.




• Make it about updates. Say that if it changes a few times a year, rebuilding the file each time keeps coming back.

Splitting it that way changed what the conversation is about.

• It stopped being a yes-or-no on accessibility and became a question of which documents go which way.




• For the ones staying as PDFs, we could offer a third option: a one-page summary in HTML.




• With the criteria in the pre-launch list, different people now apply them in the same order.

Lead with the word accessibility and it becomes a yes-or-no decision. Split it into readers, findability, and maintenance effort, and the decision gets concrete.

The limits: HTML alone doesn’t fix it

So you don’t expect too much, here’s where it stops.

Moving to HTML doesn’t make a document readable by itself. Skip a heading level, or use a table for layout, and the same problems show up on the HTML side. Choosing the format and structuring the content are two separate jobs.

You also don’t need to rebuild every PDF you’ve already published at once. Start with the documents that get the most views and the ones that change most often. That’s where the effort pays back fastest.

FAQ

Q. Should we avoid publishing PDFs?
A. You don’t need to avoid PDFs. What’s recommended is asking whether the PDF is necessary first. Japan’s Digital Agency states in its own accessibility test results that where there’s no real need for a PDF, a web page should be provided. Documents meant to be printed, and forms where a broken layout changes the meaning, are a good fit for PDF.

Q. Do PDFs show up in search?
A. PDFs do get indexed, but getting someone to a specific spot inside the document is hard. If you want to point readers at the exact page they need, an HTML page takes fewer steps on their side.

Q. Do we have to rebuild every PDF we’ve already published?
A. Not all at once. Start with the documents that get the most views and the ones that change most often, and move those to HTML first. For the ones staying as PDFs for now, a one-page summary gives them an entrance.

Q. What’s the minimum for PDF accessibility?
A. Four things: set the file title, set the language, add structure for headings, tables, and lists, and add alt text to figures while checking the reading order. Structure and alt text are faster to handle in the source file than in the exported PDF.

Q. How do we share the criteria across the team?
A. Write the five checks into your pre-launch review list and apply them in the same order every time you publish. That cuts the variation between people. Recording why you decided each way saves you from rerunning the same debate when staff change.

Wrap-up

• Japan’s Digital Agency, in the web accessibility test results published on March 31, 2026, states that where there is no real need for a PDF, a web page should be provided.




• The PDF issues from that same testing were missing tags, language settings, and file titles, insufficient structure for alt text, headings, tables, and lists, and no reading order set.




• If you need it found in search, plan to update it, expect phone readers, want parts quoted, or expect screen-reader use, HTML is the better fit.




• Documents meant to be printed, forms where a broken layout changes the meaning, and files that must be preserved unaltered are a good fit for PDF.




• Even when you publish a PDF, you still need the file title and language set, structure added for headings, tables, and lists, and alt text plus reading order checked.




• For the client conversation, split it into readers, findability, and maintenance effort. That’s what makes the decision concrete.

Put the five checks into your pre-launch list so you’re not re-deciding this from scratch every time something goes up.

MONJI+, a Collaborative AI WebOps Platform

MONJI+ grew out of the problems we kept running into on real sites.
We never aimed to ship something finished from day one. We built it piece by piece, alongside the people doing the work.

▼About MONJI+
https://monji.tech/plus/

▼Start free
A 30-day trial gives you every feature. There is also a Free plan that stays free.
https://monji.tech/plus/trial/

▼Sign up and start using it
https://tool.monji.tech/signup