PDFSmart news

Standards, engineering and support: how we make PDFSmart

August 28, 2026

Standards, engineering and support: how we make PDFSmart

Most people meet a PDF at the worst possible moment. A contract that has to be signed today. A form that will not accept the scan. A hundred-page report that looked correct on one screen and came apart on another.

The format itself is not the problem. PDF is remarkably stable, and that is precisely why it is everywhere. It has been an open ISO standard since 2008, maintained in public by an international committee rather than owned by any single company. A file written correctly today will still open correctly in twenty years.

The tools built on top of that standard are not all equally faithful to it. That gap is where most PDF frustration actually comes from, and it is where we spend the bulk of our engineering time.

Why we joined the PDF Association

In January 2026, PDFSmart became a Full Member of the PDF Association.

The Association is the industry body that maintains a shared understanding of ISO-standardised PDF technology. It holds liaison status with ISO TC 171, the committee responsible for the format, and it produces the technical notes, guidelines and test suites that implementers build against. Its membership runs from independent developers through to Boeing and the United States Government Publishing Office.

Full membership gives us access to the working discussions behind those publications: the context, the disagreements, the reasoning that never makes it into the final specification. For a company whose entire product sits on top of the standard, that is not a badge. It is a source of information we would otherwise have to guess at.

We are members rather than authors of the specification, and we are not going to suggest otherwise. But we build to it deliberately, and we think users are entitled to know which tools do.

What building to the standard actually means

A PDF tool can produce a file that opens and still be doing something wrong. The interesting questions are the ones a user never sees:

  • When you compress a document, what is the tool allowed to discard? Downsampling an image is one thing. Dropping the structural information that lets a screen reader work through the page is another.
  • When you run OCR on a scan, does the recovered text layer align with what is visually on the page, or does it merely sit somewhere behind it?
  • When a document claims conformance with PDF/A, the archival subset, does it genuinely meet the requirements, or does it just carry the label?
  • When you merge two files, what happens to their form fields, their bookmarks, their digital signatures?

These are the decisions that separate a tool that works from a tool that appears to work. They are also invisible until the moment they matter, which is usually the moment a document has to be filed, submitted or archived.

Across editing, conversion, compression, OCR, signature and archival tooling, we build against the specification rather than against what happens to render acceptably in a browser.

Rebuilding how we support people

Technical correctness is not much comfort to someone who cannot get a straight answer when something goes wrong.

Earlier this year we took our first-line support apart and rebuilt it. The model we had leaned heavily on templated replies. That approach is cheap to run and quick to look responsive, and it is very good at making a person repeat themselves. If your question does not match a template, a template does not help you.

Requests that turn on account data, subscription status, billing history, the state of a document, are now resolved directly rather than routed into a template queue. Anything that needs judgement goes to a named team with the account context already attached, so the person answering can see what happened without asking you to recount it. 

We are not going to describe this as solved. It is a change in how we work rather than a finished project, and the standard we hold ourselves to is simple: a person should not have to explain the same problem twice, and should not have to ask twice to get an actual answer.

What comes next

Two things, over the coming months.

The first is accessibility. PDF/UA, the accessibility subset of the standard, is one of the least implemented and most consequential parts of the format. 

The second is clarity. Documents are personal, and the services that handle them should be legible: what the tool does, what happens to your file, what you are signing up for and how to change your mind. We would rather be explicit about that than assume it is understood.

PDFSmart is a Full Member of the PDF Association. You can find our entry, alongside the rest of the membership, at pdfa.org.

FAQ

Is PDFSmart a member of the PDF Association? Yes. PDFSmart has been a Full Member since January 2026. The Association is the industry body that maintains a shared understanding of ISO-standardised PDF technology and holds liaison status with ISO TC 171, the committee responsible for the format.

Does PDFSmart contribute to the PDF specification? No. We are members rather than authors of the specification. Membership gives us access to the working discussions behind the Association's technical publications, which informs how we build, but the standard itself is maintained by ISO.

What does ISO 32000 mean for a PDF tool? It is the specification that defines the format. A tool can produce a file that opens correctly and still handle it wrongly underneath, for example by discarding the structural information a screen reader depends on. Building to the specification rather than to what renders acceptably in a browser is the difference.

What is PDF/UA? The accessibility subset of the PDF standard. It defines how a document carries the structure that assistive technology uses to navigate it. It is one of the least implemented parts of the format.