Inspect any PDF.

This inspector reads any PDF in your browser. There is no upload. We have no server-side record of which files you inspect. The parser itself ships from this site, with no third-party CDN call and no remote dependency at inspection time. The inspection is entirely a conversation between the file and your browser.

Drop a PDF below. The inspector will read its tagged structure tree, its XMP metadata packet, and the AI-governance provenance record if one is embedded. It will then classify the file into one of three tiers (MX Compatible, EAA tagged only, or plain, and surface what each tier means in plain language. You can download the inspection results as a machine-readable JSON, a human-readable markdown report, or (when present) the embedded AI provenance record lifted out for offline analysis.

For the conceptual background, what each of these artefacts is, why they matter under the European Accessibility Act and the EU AI Act, and how to verify any claim with three command-line tools, read the explainer: MX for PDFs. The inspector is the interactive companion; the explainer is the walk-through.

Drop the file

What the inspector checks

Four artefacts, in order of evidence weight.

Tagged structure (ISO 14289-1)

An MX Compatible PDF declares pdfuaid:part=1 in its XMP metadata packet, indicating PDF/UA-1 conformance to ISO 14289-1. The inspector reads the XMP packet and reports the declared Part. The tagged structure tree itself (the /StructTreeRoot in the PDF's catalog) is what lets a screen reader walk the document the way a sighted reader does, and what European Accessibility Act Directive 2019/882 expects for documents published from 28 June 2025 onwards.

Note: This page describes regulatory frameworks in general terms only. Nothing here is legal advice. Requirements vary by jurisdiction, organisation type, and use case. Consult qualified legal specialists for guidance specific to your situation.

MX XMP namespace

An MX Compatible PDF carries a packet of MX-namespaced metadata in its XMP stream: status, content type, canonical URL, source repository, audience, conformance claims, and several other fields. The inspector probes for these fields and reports the first one found, plus its value, as evidence that the MX packet is present. The namespace URI is https://mx.allabout.network/ns/1.0.

Provenance AI payload

Every MX Compatible PDF this hub produces carries an AI-governance provenance record embedded inside the XMP packet under mx:ProvenanceAiPayload. The record is JSON. The inspector extracts it, parses it, and reports the number of steps recorded and the named operator. If the embedded record parses cleanly, you can download it as a standalone JSON file via the downloads panel.

Responsible Person Identifier

The responsible person block names the human accountable for the file's audit chain: name, email, identifier URL, role, organisation, and country. The inspector reads it from the XMP packet (or from the embedded provenance payload as a fallback). The block is what regulators ask for under EU AI Act Article 4, the UK ICO accountability principle, the NIST AI Risk Management Framework, and EAA Directive 2019/882.

What the three tiers mean

The inspector classifies every file into one of three tiers.

MX Compatible. The file declares a tagged structure tree and includes the MX XMP namespace. It is accessible, attested, and machine-readable. This is the bar the MX Compatible badge represents.

EAA tagged only. The file declares a tagged structure tree but no MX namespace. It is accessible (Screen readers can walk it; EAA Directive 2019/882 conformance is plausible) but it is not attested. A regulator or AI agent cannot verify what the file claims or who authored it.

Plain PDF. The file does not declare a tagged structure tree. A screen reader has to guess. An AI agent has to do vision-based reconstruction. The European Accessibility Act compliance bar set on 28 June 2025 is not met.

The MX Compatible badge

If you arrived here by scanning a QR code, this is the badge you scanned. Every PDF this hub produces carries it: on the cover for reports and books, on the closing page for letters and briefings. The badge is not decoration. It is a short, readable summary of the evidence inside the file, and the QR resolves to this page so any reader can test the claim against their own copy.

Under the wordmark, the badge prints one conformance line:

ISO 14289-1 Level 2 · pdfuaid:Part=1 · Provenance: EU AI Act · UK ICO · NIST AI RMF · EAA Directive 2019/882

That line is built to be read by four audiences at once. A European reader, a British reader, and an American reader each find an instrument they know. The fourth reader is a machine. An AI agent, a screen reader, or a regulator's validator does not read the visible badge; it reads the tagged structure, the XMP packet, and the provenance record the badge advertises. The badge is for eyes, the artefacts are for machines, and both say the same thing. All four rest on one international standards baseline that belongs to none of them and serves all of them.

The citations are claims of relevance, not grants of compliance. Producing a tagged, attested PDF does not make a company compliant with any of these instruments; that remains the company's legal duty. What the file does is carry the structured, machine-readable, verifiable evidence each of these frameworks expects a company to be able to produce on request. Drop the file above and the inspector shows you whether the badge on it is backed by the artefacts it names, or whether the badge is making a promise the bytes do not keep.

Why this is not server-side

Some inspectors upload your PDF to their server, parse it there, and email you results. We do not. There are three reasons:

Privacy. The PDF you drop on this page may be confidential, a draft contract, a board paper, a medical record, a tax return. We do not want a copy. The inspector is built so that we cannot have one.

Verifiability. An inspection you can re-run locally, on the same file, with the same code, is more trustworthy than a server-side process you cannot see. The full inspector source ships in your browser, including the PDF parser itself, vendored into this site rather than fetched from a third-party CDN. Once the page loads, the inspector runs without any further network calls. You can read the source, copy it, run it offline.

Cost honesty. A free service that pays for itself in inspection volume eventually monetises in ways the visitor did not sign up for. We make our money from rebuilding documents into MX Compatible PDFs, not from inspecting yours.

We run every PDF we ship through this tool

Every PDF we produce goes through this same inspector before it leaves our hands. The production pipeline calls the harness at tests/test-pdf-inspector.js against every artefact the renderer emits, audit reports, books, briefings, contracts. If the inspector does not certify the file as MX Compatible, the build fails and nothing ships. The browser inspector you see on this page and the production gate share one source of truth, the detection core at mx-outputs/mx-site/js/pdf-inspector-core.js, so a regression in either surface fails both.

The reports we send to clients and the books we publish are not asked to meet the MX Compatible bar by hand and by hope; they are blocked from shipping unless they meet it by machine. When you drop a PDF we produced into this inspector, you should see the same verdict the build saw before it released the file.

Credibility by mechanism, not by claim

Three things have to line up before a PDF we send you carries a real MX Compatible verdict. The page you are looking at must say so. The production gate must enforce it. The test harness must prove it. All three live in the open. This page makes the claim. The gate at scripts/bin/mx.pdf.sh hard-fails the build when a PDF does not meet the bar. The harness at tests/test-pdf-inspector.js walks the same checks against the gold-standard fixture and exits non-zero on regression, every time npm test runs.

Each layer reads from the same source. The detection core at mx-outputs/mx-site/js/pdf-inspector-core.js is shared by the inspector you are running and the gate that protects our outbound work. When the producer changes, when pdf.js changes, when the inspector changes, the same code path is exercised by both surfaces. A regression cannot quietly drift between them; if the harness fails, the gate fails, and the inspector fails for every visitor in the same way.

This is the argument MX makes generally and that the inspector demonstrates specifically. Not "trust us, we did this carefully" but "here is the file, here is the rule, here is the check, run any of them yourself, decide for yourself." For the EU AI Act, the European Accessibility Act, and the AI-governance instruments emerging in adjacent jurisdictions, that distinction matters. An auditor holding the file can walk to the rule, walk to the check, and arrive at the same verdict the build saw. No proprietary intermediary, no closed-source verifier, no "ask the vendor."

The mechanism is the credibility. That is why we run every PDF through this tool, and why the tool runs in your browser when you ask it to.