Small files, clear test cases.

Why the site exists

Testing a PDF feature often starts with a surprisingly simple problem: you need a file that is safe to share, predictable enough to reuse, and small enough that the file itself does not hide the behavior you are trying to test. Real invoices, resumes, medical forms, bank statements, contracts, and customer uploads are poor fixtures because they may contain private data and they change from case to case.

samplepdf.org solves that narrow problem by providing purpose-built sample documents. The site is not a document marketplace and it is not a repository of scraped PDFs. The core files are synthetic fixtures generated for testing and demonstrations.

How the core PDF fixtures are created

The repository includes a local generator that writes small standards-based PDF 1.4 files. The generator defines the catalog, page tree, page object, Helvetica font resource, content stream, cross-reference table, trailer, and EOF marker directly. This makes the simplest fixtures easy to inspect and keeps their behavior predictable.

The general-purpose variants are intentionally different:

What we verify

For core fixtures, we record stable characteristics that can be checked again after a change. These include the byte size, filename, expected purpose, PDF signature, and SHA-256 hash. For example, the current sample.pdf is 843 bytes and its SHA-256 is f1054db56eaef90249677915b7604f075faf01756529f85dfdc1660b8f27b88d.

A hash is useful because it answers a different question than a visual preview: it tells you whether the exact file bytes changed. That is useful for regression tests, bug reports, and CI fixtures where a silent file change can make a previously reproducible test inconsistent.

Our editorial approach

Each page should answer a concrete testing or document-use question rather than repeat the same download description with a different keyword. A page about downloading focuses on request behavior and file retrieval. A page about the PDF file itself focuses on file structure and parser expectations. A testing page focuses on test goals, expected results, and common failure modes. Document examples such as resumes, meeting agendas, and business proposals are intended to explain the structure and use of that document type in addition to offering a sample file.

We prefer specific observations over generic claims. Where a page lists a byte size or hash, it should match the file in the repository. Where a page explains a test outcome, it should say what is being tested and what a failure would mean. We also avoid using real personal records as demonstration content.

What these files are not

• They are not copies of confidential customer documents.
• They are not official forms issued by Adobe, Google, Microsoft, a government agency, or another third party.
• They are not intended to prove compatibility with every PDF feature, parser, font, form type, encryption method, or malformed-file edge case.
• They are not legal, medical, financial, employment, or professional advice.

When your test depends on a complex PDF feature, use the simplest fixture that reproduces the behavior and then add a dedicated edge-case fixture for that feature.

Independence and naming

samplepdf.org is an independent testing resource. Product and company names may be mentioned to describe common workflows, browsers, libraries, or advertising and analytics services, but those mentions do not imply sponsorship or affiliation unless explicitly stated.

Questions or corrections

If a sample file does not match the details shown on its page, a link is broken, or a testing explanation can be improved, please use the Contact page. Privacy questions are covered separately in the Privacy Policy.