Is the generated PDF safe to share publicly?

Yes. Nothing in it is real — the text is placeholder assembled from a fixed word list, the invoices and tables carry made-up values, and no metadata about you is written into the file. It is designed to be the thing you attach to a public issue instead of a real document.

Can I generate a PDF of an exact file size?

Close, not exact. The generator pads the document until it lands near the figure you set, normally within a few percent. PDF compresses its contents, so no generator can promise an exact byte count. Generate one either side of a limit if you need to test the boundary precisely.

How large a document can it build?

Up to 500 pages per file and up to 20 files at once. It is all built in your browser, so a 500-page document takes a few seconds on a laptop and noticeably longer on a phone.

Which content type should I pick if I am not sure?

Big page numbers. It is the only one that makes an ordering mistake visible at a glance, which is the failure mode most PDF handling actually has. Switch to article or table layouts once you are specifically testing text or data extraction.

Does it need an internet connection?

Only to load the page the first time. The document is assembled by code running in your browser and written straight to a download, so once the tool has loaded it keeps working offline.

how to create a test pdf file

How to Generate Sample PDFs for Testing

The PDF you need to test with is almost never the PDF on your desk. That one is confidential, the wrong length, and has none of the properties you are trying to break.

Why a made-up PDF beats a real one

Anyone building software that touches PDFs hits the same wall early: you need a file, and the files to hand are payslips, contracts and client reports. Attaching one to a bug ticket is how confidential documents end up in an issue tracker forever. Using one as a test fixture is how they end up committed to a repository.

The other problem is shape. Real documents are whatever length they happen to be. Testing that a merge preserved page order needs a document whose pages announce their own number. Testing an upload limit needs a file just over it. Testing a paginated viewer needs 300 pages, and nobody has a 300-page document lying around they are willing to share.

Generating one solves both. The generator here builds the document in your browser and hands it straight to a download — nothing is uploaded, and nothing about the file needs redacting later, because there was never anything real in it.

The settings, and what each one is for

There are eight of them and they map onto specific testing jobs rather than being decoration.

Document title: Becomes three things at once: the PDF's title metadata, the heading on page one, and the download filename. Useful when you are generating several fixtures and need to tell them apart in a folder.
Pages: One to 500. The number to reach for when you are testing pagination, page-range parsing, or how a viewer behaves once a document stops fitting in memory comfortably.
Number of files: One to 20, each independently numbered and named. This is the setting for testing anything that consumes several documents at once.
Page content: Nine layouts, covered below. This is the one that decides what the fixture is actually good for.
Typeface: Helvetica, Times or Courier — the three faces built into every PDF reader, so no font is embedded and the file stays small and portable. Courier is the one to pick when you are testing fixed-width extraction.
Page size and orientation: A4, US Letter or Legal, portrait or landscape. Worth varying: a surprising amount of PDF handling is written against A4 and quietly mishandles Letter, and landscape breaks layout assumptions that portrait never exposes.
Approximate file size: Zero for a small file, or a figure in megabytes to pad the document until it lands near it.
Page numbers: A printed number on every page, on by default. Leave it on unless you are specifically testing a document without them — it costs nothing and it is the fastest way to see that something went wrong.

Nine kinds of page, and what each one tests

The content setting is not cosmetic. Each layout exists because a different part of a PDF pipeline needs a different thing on the page.

Big page numbers: The default, and the right default. One enormous numeral per page means a glance at the output tells you whether a merge, split, rotate or reorder did what you asked. Nothing else makes an ordering bug this obvious.
Lorem ipsum paragraphs: Dense running text. What you want when testing text extraction, search indexing, or how a converter handles paragraph flow.
Headings, paragraphs and bullets: Structured prose. This is the fixture for PDF-to-Word and PDF-to-Markdown, because it has a document hierarchy for the converter to infer.
Data tables: Ruled rows and columns. The input for testing PDF-to-Excel and PDF-to-CSV, where the hard part is recovering cell boundaries from what is really just lines and positioned text.
Invoices: Line items, totals, addresses and reference numbers. The realistic shape for testing document parsing, field extraction, or anything that claims to read invoices.
Form fields: Labelled boxes and rules. Use this for flattening, signature placement, and anything that has to leave form furniture intact.
Bar charts: Vector graphics rather than text. Good for testing rasterisation, PDF-to-image output, and compressors that treat drawings differently from photographs.
A mix of everything: Rotates through the layouts across the document. The closest thing to a real report, and the best single choice when you want one fixture that exercises most paths.
Blank pages: Deliberately empty. For testing page-count handling, blank-page detection, and what happens when extraction correctly finds nothing.

Hitting a file size on purpose

The approximate file size setting is the one people arrive looking for, usually because something rejected an upload and they want to find the actual limit rather than trust the error message. Set a figure in megabytes and the generator pads the document with incompressible data until the file lands near it.

It is described as approximate for an honest reason. PDF is a compressed format, and the final byte count depends on how the content and the padding compress together — the result normally lands within a few percent, not on the exact number. If you need to test a hard boundary, generate one file just under and one just over, and let the pair bracket the limit.

The other use for it is performance. A 40 MB document is how you find out whether a viewer streams pages or tries to load the whole file, and whether a progress bar is real or decorative.

Batches, for anything that eats more than one file

Set the number of files above one and you get that many separate documents, each with its own numbering and its own filename, plus a ZIP of the whole batch. This is the fastest way to produce merge input: five files of five numbered pages each, merged, should give you 25 pages counting from one to five, five times — and any deviation from that is visible immediately.

It is equally useful for anything with a queue: testing that a multi-file upload handles all of them, that a batch converter does not drop the last item, or that a progress indicator counts correctly.

The same settings always produce the same document

The placeholder text is assembled from a fixed word list rather than randomised, so generating with identical settings twice gives you an identical document. That is what makes the output usable as a committed test fixture: it can be diffed, checksummed, and compared against a previous run without every regeneration producing spurious differences.

It also means a bug report can say "generate five pages of numbered content at A4" and the person reading it gets exactly the file you had, which is a great deal better than attaching one.