The simplest possible PDF question
"How many pages is this PDF?" People type that question into Google thousands of times a day. It sounds trivial because it is trivial — and yet every desktop PDF reader buries the answer in a menu, and most mobile readers don't show it at all. So the question keeps getting asked, and people keep clicking through ad-stuffed pages to find out.
The PDF Page Counter is the no-fuss answer: drop a PDF, see the page count in big numbers. Below it, the file size and the average bytes per page. Below that, a table of every metadata field the PDF embedded — title, author, subject, creator app, PDF producer, creation date, modification date. No conversion. No download. No "click here to extract." Just the answer.
The whole thing runs in your browser using pdf-lib. The PDF never leaves your machine. There's no upload step at all, because there's no server step at all.
How to use it
- Drop a PDF onto the page, or pick one from a file dialog. Up to 200 MB — higher than our other PDF tools because counting pages only reads the catalog, not the page contents, so memory stays minimal regardless of file size.
- The page count appears immediately, formatted as one big number. The file size and bytes-per-page heuristic show next to it.
- Below, the metadata table fills in with whatever fields the PDF set. Empty fields show as
—(an em-dash). That's not a tool error — it's just the source data.
No account. No watermark on anything, because there's no output to watermark. No daily cap. Free is a fact.
Why this is worth a tool. "How many pages is this PDF" is one of the highest-volume PDF questions on Google. Every desktop reader puts the answer at least two clicks deep — File → Properties, or some equivalent buried in a menu. Every mobile reader skips showing it at all. A web tool that gives the count plus the full metadata table in under two seconds, with no upload, beats every existing option. We built it because the gap was obvious.
What the metadata table tells you
Every PDF can carry a "document information dictionary" — a small set of fields the creator app may or may not have filled in. The PDF spec defines seven standard fields, and we surface all of them.
| Field | What it is | Typical value |
|---|---|---|
| Title | The document's title (free text) | Often blank for casually-made PDFs; set on PDFs from publishing tools |
| Author | The document's author | Often blank; sometimes a username, sometimes a full name |
| Subject | A short description | Almost always blank in the wild |
| Keywords | Comma-separated tags | Almost always blank |
| Creator | The app the user opened to make the PDF | "Microsoft Word", "Adobe InDesign 2024", "Google Docs", "Skia/PDF" (Chrome's print-to-PDF) |
| Producer | The library that wrote the actual PDF bytes | "Adobe PDF Library 15.0", "pdf-lib", "wkhtmltopdf 0.12.6", "macOS Quartz PDFContext" |
| CreationDate | When the PDF was first generated | An ISO timestamp; usually present |
| ModDate | When it was last modified | Equal to CreationDate for new PDFs; later for edited ones |
The Creator vs Producer distinction matters more than it looks. The Creator is the user-facing app — the program someone clicked into to make this PDF. The Producer is the underlying library that wrote the bytes. Together they're a forensic fingerprint. A PDF with Creator = "Microsoft Word for Office 365" and Producer = "Microsoft® Word for Microsoft 365" almost certainly came out of a recent Office install. A PDF with Creator = "Skia/PDF m118" and Producer = "Skia/PDF m118" came from someone hitting Cmd+P in Chrome and choosing "Save as PDF". A PDF with Creator = "Adobe InDesign 19.5" and Producer = "Adobe PDF Library 17.0" came from a designer working in a real publishing app.
If you've ever been handed a mystery PDF and wondered where it came from, the metadata table here is the first place to look.
The bytes-per-page heuristic
Next to the page count, we show the average kilobytes per page. It's an order-of-magnitude read on how content-heavy each page is, which tells you something useful about the document.
| Average KB/page | Typical content | Good candidate for compression? |
|---|---|---|
| 2–20 KB | Plain text, sparse formatting (legal docs, novels) | No — already small |
| 20–60 KB | Text with light formatting, some vector graphics | Not really worth it |
| 60–200 KB | Text with embedded images, mixed media | Maybe, depending on need |
| 200 KB – 1 MB | Image-heavy: brochures, photo essays, design proofs | Yes — significant savings available |
| 1 MB+ | High-res scans or photography | Yes — usually massive savings from PDF compression |
This is a shortcut for "should I bother compressing this?" or "is this PDF mostly text or mostly pictures?" — questions that come up constantly when you're sending a PDF over email or uploading to a site with a size limit.
A worked example: identifying a mystery PDF
Concrete case. A teammate forwards you a PDF labeled q3-deck.pdf with no other context. You want to know: how long is this, how big is it on disk, and where did it come from?
Drop it in. The result block fills in immediately:
- Pages: 23
- File size: 8.4 MB
- Average: 374 KB per page
- Title: Q3 2026 Business Review
- Author: jane.chen
- Subject: —
- Creator: Microsoft® PowerPoint® for Microsoft 365
- Producer: Microsoft® PowerPoint® for Microsoft 365
- CreationDate: 2026-05-08 14:22 UTC
- ModDate: 2026-05-09 09:51 UTC
You know in under two seconds: 23-page deck, came out of PowerPoint last week, made by Jane, edited once after creation, image-heavy enough that compression would meaningfully help if email rejects it. That's actually useful for the next ten seconds of your work day.
Why use this over iLovePDF, SmallPDF, or your PDF reader
iLovePDF doesn't have a dedicated page-counter tool — you'd have to upload to "Merge" or "Split" and count from there. Even on tools where they show the count, your PDF is uploading to their servers for a piece of information that's literally in the file's table of contents. Wrong shape of tool for the job.
SmallPDF the same. Page count is something some tools surface as a side effect, but again — upload, account prompt, two-document-per-hour cap. For a number that's sitting in the first few KB of the file.
Adobe Acrobat Reader shows the page count in the bottom toolbar (current page / total). That's fine for one PDF at a time, on a desktop, if you have Acrobat Reader installed. For a quick lookup across a few files, especially on mobile, this tool is faster and shows the metadata table that Acrobat hides behind File → Properties → Description.
macOS Preview shows the count in the sidebar but the metadata is buried (Tools → Show Inspector → ⓘ tab). And only works on a Mac.
The Files app on iOS or Android usually doesn't show the count at all. Tap a PDF to open it, scroll to the end, look at the page indicator — that's the workflow most mobile users actually use, which is why people keep Googling the question.
The shape of this tool is honest: it does one thing, returns one answer plus a forensic snapshot, takes two seconds, and demands nothing from you.
Related PDF tools
- Extract Text from PDF — once you know how long the PDF is, pull the words out as plain UTF-8. Not OCR; works on text-bearing PDFs.
- Extract Images from PDF — pull embedded photos, logos, and screenshots out as separate PNG files at original resolution.
- PDF Merger — combine several PDFs into one. Page counter is useful before merging if you want to predict the result length.
- Split PDF — break a long PDF into smaller chunks (by range or by single pages).
- Compress PDF — if the bytes-per-page reading is in the 200 KB+ range, this is where to go next.
- PDF Metadata Editor — if the title/author is wrong (or blank) and you want to fix it.
Frequently asked questions
Is this really worth a tool?
"How many pages is this PDF" is one of the top PDF-related search queries on Google — people genuinely ask this thousands of times a day. Every desktop PDF reader buries the answer; every mobile reader skips it. A web tool that gives the count in 2 seconds, with no upload and no quota, fills a real gap. We cost nothing to run; it's a small kindness.
What metadata fields do you read?
All seven standard PDF document-info fields: Title, Author, Subject, Keywords, Creator (the app the user used — Word, InDesign, etc.), Producer (the PDF library that generated the bytes), CreationDate, ModDate. Some PDFs also embed XMP metadata, which we don't surface in v1. If you'd find that useful, tell us.
Why is the title and author often blank?
Because most apps don't ask the user to set them, and most users never visit File → Properties to fill them in. Publishing tools (Acrobat, InDesign, LaTeX with proper preamble) often set them; consumer tools (Word with default settings, browsers' "Save as PDF", smartphone scan apps) often don't. A blank field isn't a bug here — it's just empty in the source.
Is my PDF really not uploaded?
Correct. The count runs in your browser via pdf-lib. We only read the PDF's catalog — we don't even need to decode page contents to count them. Zero outbound requests. Check your browser's network tab while you drop the file in; you'll see nothing fire.
Does this work on password-protected PDFs?
Yes, for page count and basic metadata. We load with ignoreEncryption: true, which lets us read the document catalog (where the page count lives) without the password. This does not let you read or extract page contents — that still requires the password. We're reading metadata about the document, not the document itself.
What's the difference between Creator and Producer?
The PDF spec defines Creator as "the app the user interacted with" — Microsoft Word, Adobe InDesign, Google Docs, your browser's print dialog. Producer is "the library that wrote the actual PDF bytes" — Adobe PDF Library, pdf-lib, wkhtmltopdf, Skia/PDF. They often differ. A PDF from InDesign typically has Creator = "Adobe InDesign 19.5" and Producer = "Adobe PDF Library 17.0". A PDF from Chrome's print dialog has both set to a Skia variant. Together they're a forensic signature for the document's origin.
What's the maximum file size?
200 MB. We bumped it past our usual 100 MB limit because this tool only reads metadata — it doesn't render pages or hold them in memory — so the file size mostly doesn't matter. Even a 200 MB PDF only needs the catalog parsed, which is small.
Why is "average KB per page" useful?
It tells you quickly whether the PDF is text-heavy or image-heavy. Text pages run 2–20 KB. Pages with one or two images run 50–200 KB. Image-dense pages (brochures, photo books) run 200 KB to 1 MB. High-res scans run 1–5 MB per page. If your PDF averages over 200 KB per page and you're hitting a size limit somewhere, PDF compression will help meaningfully. If it averages under 20 KB, compression won't gain much.