To get a PDF page count in JavaScript, load the file with a PDF parsing library such as pdf-lib and call the library's getPageCount() method on the parsed document — the number you receive is the structural count of pages stored in the PDF's page tree, not an estimate from file size or a count of printed sheets or visible page-number labels. The page tree is part of every conforming PDF, so the approach works on any non-encrypted, well-formed document and returns as soon as parsing finishes. If you only need a one-off answer for a single PDF and don't want to set up Node, a bundler, an npm package, or a server endpoint, the same structural count is what the PDF Page Counter shows in your browser. Both methods read the PDF locally, both ignore duplex print settings and any "page 3 of 12" labels printed inside the file, and both keep the document on your own machine. The decision between them comes down to whether you need the count inside a running JavaScript application or just need a fast private inspection of one file.
Why JavaScript developers need a reliable page count
Page count drives decisions in almost every browser-side PDF workflow. Validation gates on upload forms use it to reject files that exceed a limit. Front-ends for splitting, merging, and reordering tools render range pickers that depend on a current maximum. Print estimators branch on whether a document is 2 pages or 220 pages because the cost math is different at every order of magnitude. QA checks detect corrupted or relabeled files when the visible "Page 1 of 6" footer disagrees with the structural count inside the document.
Because the page count often controls logic, the source has to be trustworthy. Two numbers commonly appear in PDFs: the structural count from the page tree and the visible labels printed onto pages. They should match, but they don't always — a document can label its pages with Roman numerals, start numbering at 3, or stamp "Page 1" on the cover. Reading the structural count removes that ambiguity and lets a JavaScript app behave predictably even when authors renumber their pages for printing. The PDF specification defines this count through a single root /Pages object whose integer /Count entry is what every conformant parser returns.
Count pages in JavaScript with pdf-lib
pdf-lib is a Mozilla-licensed PDF library that runs in Node and the browser and exposes the page tree directly. The minimum browser pattern has three pieces. First, an async helper that turns a File into a page count: read the file with file.arrayBuffer(), pass the buffer to PDFDocument.load(), and return pdf.getPageCount(). Second, a change handler on a file input element that picks up the user's selection and writes the result back into the page. Third, a small piece of HTML — a file input and a target output element — to anchor both pieces. Together that is the entire minimum viable page-counter integration on the client side.
The same parsed document exposes per-page geometry. After PDFDocument.load() returns, the first page's MediaBox dimensions in PDF points are available through PDFPage.getSize(), which returns an object with width and height keys. Logging both to the console surfaces 612 by 792 for a US-Letter PDF and 595.28 by 841.89 for an A4 PDF. Iterating with pdf.getPages() lets you collect every page's dimensions into a map so you can implement the same first-seen grouping behavior that the no-code tool offers.
A few constraints follow from the underlying API documented at the PDFDocument.getPageCount page: encrypted PDFs throw unless decrypted first, empty PDFs throw at load(), and the returned number is always the structural count — independent of rotation metadata, paper-size labels, or any rendering pass. The size call follows the same shape and is documented at PDFPage.getSize. Treat both calls as a read-only inspection step inside JavaScript and let dedicated PDF tools handle anything that would create a new file.
Get the page count without writing JavaScript
When you don't need code and just want to know how many pages a single PDF contains — for an upload check, a print estimate, a splitting plan, or document QA — the local PDF Page Counter tool runs the same parse and skips the integration steps entirely. Everything happens in your current tab. The file is read but never uploaded, and no modified copy is written. The browser finishes loading the document's page tree before any number appears, and a job identifier inside the tool keeps a slower older read from replacing the result of a newer one.
- Open PDF Page Counter in your browser and choose a non-empty PDF no larger than 25 MiB.
- Wait for the browser to read the document's page tree — the total page count appears once parsing finishes.
- Review the total and the grouped page-box dimensions: equal widths and heights are collapsed so a file with two 612 by 792 pt pages and one 400 by 500 pt page reports both sizes and their counts in first-seen order.
Selecting another file clears the previous result before processing begins, so the displayed count always belongs to the named current file. Files outside the 25 MiB limit, encrypted documents without a known password, and damaged cross-reference tables surface as visible errors instead of silent zeros, and the operation remains strictly read-only throughout.
What the result includes, and what it leaves out
The headline number is the exact length of the document's /Pages array — the structural page count. It is not derived from the file size, from a thumbnail rendering pass, from a sheet count under any duplex or N-up layout, or from the page numbers printed onto the pages. The same distinction holds on the JavaScript side, since both code and tool read the same field through the same underlying PDF library.
For every page, the result also reports the width and height of the current page box in PDF points, where a point is 1/72 of an inch and is defined by the file's geometry — not by your monitor or printer. Two decimal places are the maximum displayed precision, and equal displayed sizes are grouped together in first-seen order. Rotation metadata can affect how a viewer presents a page, but the reported width and height stay locked to the page-box values the document library returns; rotation is never rewritten and no page is normalized. Boxes are not labeled A4, Letter, or any other paper standard, because mapping points to a named paper format would require both an orientation decision and a tolerance threshold that could mislead mixed-size files.
The counter does not estimate printing cost, count annotations, detect blank pages, count physical duplex sheets, render thumbnails, or add metadata. No download is created because the source is not changed, and the result exists only in the page until another file is chosen or the tab closes.
Reading the page-box dimensions
Because the values are reported in PDF points, a quick lookup helps when scanning the grouped output. The table below maps points to inches and millimeters for several common paper standards — these are the values the file itself should contain if it was prepared against a standard paper size and was not resized or rotated. Treat the numbers as geometry, not as a quality score: a large point size can hold low-resolution imagery, and a small point size can hold vector artwork that prints cleanly at any scale.
| Paper standard | Width × Height (pt) | Width × Height (in) | Width × Height (mm) |
|---|---|---|---|
| US Letter | 612 × 792 | 8.5 × 11 | 215.9 × 279.4 |
| US Legal | 612 × 1008 | 8.5 × 14 | 215.9 × 355.6 |
| US Tabloid / Ledger | 792 × 1224 | 11 × 17 | 279.4 × 431.8 |
| A4 | 595.28 × 841.89 | 8.27 × 11.69 | 210 × 297 |
| A3 | 841.89 × 1190.55 | 11.69 × 16.54 | 297 × 420 |
| A5 | 419.53 × 595.28 | 5.83 × 8.27 | 148 × 210 |
To go from points to millimeters, multiply by the conversion factor 25.4 mm ÷ 72 pt. For a US Letter page reported as 612 by 792 pt, the math works out as follows.
- Width: 612 pt × 25.4 mm ÷ 72 pt = 15,544.8 ÷ 72 = 215.90 mm (≈ 8.5 in).
- Height: 792 pt × 25.4 mm ÷ 72 pt = 20,116.8 ÷ 72 = 279.40 mm (≈ 11 in).
A page whose width and height match one of these rows usually points to a document prepared against that standard. A match against the wrong orientation, or a point value that falls between rows, often points to a non-standard MediaBox, a trimmed CropBox, or a scanned insert whose original size was never standardized.
Common follow-up tasks once you know the count
The page count is usually the input for the next step. A file that exceeds an upload limit needs to shrink before it can be sent. A file with mixed page boxes needs to be split at the boundaries. A file that should have started at "Page 1" but starts at "Page 3" needs page numbers stamped onto it. None of those actions inspect the file — they modify a copy. For those, the catalog of local PDF tools covers every common next step.
- For a file that is too large to submit, run it through Compress PDF to reduce it locally, or Split PDF to break it into smaller ranges before uploading.
- For a file with a cover, foldout, or insert that should become its own document, use Split PDF by custom ranges or Extract PDF Pages to copy the chosen pages into a fresh file.
- For a document whose visible page numbers start at the wrong number, stamp new numbering with Add Page Numbers to PDF.
- For a file whose pages arrived out of order, reorder them with Rearrange PDF Pages.
- For a file that should be resized onto a single standard paper format, run Resize PDF.
The counter remains a fast private inspection step that does not touch the original bytes, so it is safe to rerun after each modification to confirm that the structural count matches the page numbers you expect on the output.