PDF Tools Without Uploading: What Can Actually Be Done Locally

Read a PDF's structure in your browser before sending it anywhere. Page count, encryption, embedded files and scripts, with an honest account of what still needs another tool.

By Print Studio Published 2026-09-17 Updated 2026-09-17

Drop a PDF on the box below and the page reads its structure — page count, encryption, embedded files, embedded scripts, the software that produced it — without sending it anywhere. The first report is a sample generated inside your browser so you can see the format.

Read in this browser, not on a server. The file is opened as a local object, the bytes are inspected in memory, and the report counts its own network requests so you can verify that number stays at zero.

Open a PDF from this device

Drag a file onto this box, or use the button above. Files up to 60 MB are read in memory; nothing is stored or transmitted.

What the report tells you, field by field

Field	Read from	Why it is worth knowing before you send the file on
PDF header	The first bytes of the file	A file whose header is not near the beginning may not be a PDF at all, whatever its name says
End-of-file marker	The last two kilobytes	Its absence is the clearest sign of a truncated download or a partial copy
Pages declared in the page tree	The page tree’s count, with a fallback count of page objects	A count that disagrees with what your viewer shows means the file has been assembled or edited by something unusual
Encrypted	The presence of an encryption dictionary	An encrypted file carries permission flags; a recipient may not be able to print or extract text from it
Linearised for the web	The linearisation dictionary	Tells you whether the first page can be displayed before the whole file arrives
Producer / Creator	The document information dictionary	Useful for provenance: which application or library produced the file
Fillable form	The presence of an AcroForm dictionary	A form’s field values may contain personal data, and some systems reject filled forms
Embedded JavaScript	Script dictionaries	A PDF can carry script that some viewers execute. Worth knowing before the file travels to a third party
Embedded files	File attachment dictionaries	Attachments inside a PDF are invisible in most previews and easy to overlook
Images and embedded fonts	Image and font-program objects	Explains the file’s size, and whether text will render correctly on a machine without the font

The report is deliberately a list of observations rather than a score. A single number would hide exactly the distinctions that matter — an encrypted file with no images and a 40 MB scan with hundreds of them can both be “fine”, for completely different reasons.

The jobs this page does not do, and why

The searches that lead here most often ask for merging, compressing, signing, form filling or format conversion. Those are legitimate tasks, and this page does not perform any of them. That is a deliberate boundary rather than an omission, and the reasons are worth stating plainly.

Merging requires parsing page trees, rebuilding cross-reference tables and rewriting the file so that every viewer agrees on the result. A merge that mishandles bookmarks, form fields, page labels or incremental updates produces a file that opens but is subtly wrong — the failure is discovered later, by someone else, usually after the document has been signed.

Compression is really image re-encoding. The large part of a typical PDF’s size is raster images, and shrinking them means decoding, resampling and re-encoding, then rebuilding the image objects and their masks. Done badly it produces visible artefacts on text scanned at an angle, which is most scanned text.

Signing has two meanings that get conflated: drawing a signature image onto a page, which is trivial, and applying a cryptographic signature, which requires certificate handling, a trusted timestamp and a viewer that can validate the result. Drawing a picture of a signature onto a PDF produces something that looks signed and proves nothing.

Filling a form requires understanding the specific form’s field structure — appearance streams, field flags, and the difference between a field value and how it is drawn.

Conversion between formats is a rendering problem, not a file problem, and every serious implementation is a layout engine.

What is left, and what this page does, is the step that comes before all of them: knowing what is in the file. In practice that step is skipped, and a document with an embedded script, an old attachment or an unexpected encryption flag is uploaded to a website before anyone has looked at it.

A defensible order of operations before a file leaves your machine

Read the structure locally with this page. Check the page count against what you expect, and look at the encryption and embedded-file lines.
Check the file’s provenance. If it arrived as an email attachment, confirm with the sender through a different channel before acting on it. This catches more problems than any file inspection.
Decide what the recipient actually needs. A merged, compressed export is sometimes wanted when the original would do — and the original is the file whose structure you have just verified.
Prefer a tool that runs on the machine for the editing step where one is available. A desktop utility that never touches a network is not more convenient, but it removes an entire class of question.
If a website is unavoidable, compare what it asks for with what the job needs. A compression service that requests an email address is collecting something the compression does not require.
Keep a copy of the file you sent. If a document matters, an archive of the exact bytes that left your machine is worth more than a link to a service.

What this page does not establish

It does not tell you whether a file is safe. Structure is not content. Treat the report as a description of the container, never as a clearance.
It does not validate the file. A PDF that fails every structural expectation may still display correctly, and one that passes every check may still be malformed in ways that only a viewer will reveal.
The page count is an estimate on unusual files. Files that store their cross-reference data in a stream, or that have been incrementally repaired, can report a lower count than the viewer shows. The report says which basis it used.
It reads the first and last few kilobytes plus a scan of the whole buffer for object markers. It is not a parser, and it does not decompress content streams, so text inside a compressed stream is not inspected at all.
It cannot see inside an encrypted file. An encrypted document reports its encryption and little else, because the structure it would need to read is itself encrypted.

Print at the right size — how to get a PDF out of a browser at the size you intended.
Printer margin guide — the other half of the story: what the printer does to the file once it has it.
Invoice template — an example of a document people convert to PDF and send to strangers.
Receipt template — the same, for the shorter document that proves a payment.
CV vs resume — why the same document sent into two different processes is often converted twice.
Custom paper templates — the hub for the paper stock this site generates.

Keep this setup

Save the settings to your Sitefarm account. Uploaded files and generated results are not stored.

Before you hit print

Does this tool edit my PDF?

No. It reads the file's bytes and reports what the file says about itself. Nothing is rewritten, nothing is saved and nothing is transmitted. If you need a merged, compressed, signed or converted file, that work has to happen in a tool that actually rewrites PDF data.

Why not build the merging and compressing here as well?

Because doing it well is a large piece of engineering, and the field is already held by mature products. A half-working merge that silently drops a page or re-encodes images badly is worse than no tool at all. What is missing from that crowded field is the ability to look at a file locally first, so that is what this page does.

Where does the reported page count come from?

From the page tree's own count field, with a fallback that counts page objects. On a damaged file, or one that stores its cross-reference data in a stream, that number can be lower than what a viewer shows. The report says so on the page rather than pretending to be a validator.

Is a file safe to open if the report looks clean?

No. This reads the structure of the document format, not the content of the file. A PDF with no embedded scripts and no encryption dictionary can still be produced by something hostile, and vulnerabilities have existed in viewers rather than in the file format itself. Keep the viewer updated; the report is not a substitute for that.

What does the request counter in the report mean?

It counts the network requests this page has made since the page loaded. It should read zero. It is there so that the claim about local processing can be checked rather than believed: watch it while you pick a file and compare it with the network panel in your browser.

Can I print the report?

Yes, and it prints on its own without the page furniture. It is not a substitute for an audit trail, but it is a reasonable record of what a file looked like on the day it was received.