Turn pictures into a PDF at the size on paper you choose. Set the resolution a pixel count prints at, pick the paper, and see every page size and the resolution it prints at before anything is written.
Initializing in your browser…
You have a 1200 x 900 photograph and want it as a PDF page that is the size the photograph is.
Input
photo.jpg (1200 x 900 px) · the picture's own size · 300 dpi · no margin
Output
One page of 288 x 216 points, which is 4 x 3 inches, with the JPEG embedded byte for byte
A picture has a pixel count and no size, so the size it prints at is a decision expressed as a resolution: 1200 pixels is 4 inches at 300 dpi, 12.5 inches at 96, and 16.67 inches only if a pixel is read as a point, which is what makes a phone photograph come out as a poster. The table on the page gives every page's paper, the rectangle the picture will fill and the resolution it will really print at, all before the file is written. A JPEG you do not turn is copied in unchanged: poppler extracts the same SHA-256 that went in.
Turn a set of pictures into one PDF. Choose the paper, or let each page be the picture's own size at a resolution you pick, and see the page size and the printed resolution of every page before you build the file.
Phone photographs of a contract, placed on Letter or A4 at a readable resolution rather than on whatever sheet the pixel count implies.
Choose 300 dpi and "the picture's own size" and a 1200 x 900 photograph becomes a 4 by 3 inch page, which is what it is.
At 96 dpi a screenshot prints the size it was on screen, so a bug report reads the way the screen did.
One PDF instead of twenty attachments, in an order you set by dragging.
A picture has a pixel count and no size. The size it prints at is a DECISION, and it is expressed as a resolution: 1200 pixels is 4 inches at 300 dpi, 12.5 inches at 96, and 16.67 inches only if a pixel is read as a point. That last reading is what a PDF library does when it is handed a pixel count unchanged, and it is why a phone photograph so often becomes a PDF page the size of a poster. This tool asks for the resolution instead, so the paper is something you chose.
**What the settings do.** Paper is any of nine sizes, with the ISO A series derived from its own millimetres rather than rounded (A4 is 210 x 297 mm, which is 595.276 x 841.890 points, not 595 x 842), plus the picture's own size at the resolution you set. Orientation can follow each picture or be forced for the whole document. How it fits is the same vocabulary the image tools use: fit keeps the whole picture and leaves a border, fill covers the page and loses the overflow, stretch fills the page and changes the shape, and its own size places the picture at exactly the resolution chosen and says how much falls off the page if it does not fit. Margin is in points, with the inches and millimetres shown beside it.
**Every number is on the page before anything is written.** The table lists, per page, the picture's pixel count after any turns, the paper that page will be, the rectangle the picture will occupy in points, and the resolution it will actually print at. That last figure is the one nothing usually says and the one that decides whether a printed page looks like a photograph: below 100 dpi the row turns amber and a warning names the number. A stretch that distorts, a fill that crops and a margin with no room left are each said out loud with their percentages.
**A JPEG is carried through untouched.** A /DCTDecode stream in a PDF IS a JPEG file, so a JPEG that is not turned is embedded byte for byte and never re-encoded: verified by extracting it again with poppler and comparing the SHA-256 against the file that went in. A PNG goes through pdf-lib's own PNG path with its transparency intact. Anything else, and any picture you turn, is drawn into a canvas at the size the turn produces and re-encoded, which is stated on the tile so you know which of the two happened. A turn is a real turn: the picture rotates and the page follows it, where a rotation that only resizes the paper leaves a picture stretched sideways into a page it does not fit.
Everything happens in the browser. The pictures are read for their real pixel count from their own bytes (the JPEG frame header of T.81 clause B.2.2, or the PNG IHDR) rather than from the file name, so what the table says is what the file contains.
Anything your browser can decode, which in practice means JPEG, PNG, WebP, GIF, BMP and usually AVIF. JPEG and PNG are embedded directly; the rest are drawn into a canvas and re-encoded as PNG first, and each tile says which happened to it.
It should not be any more. A pixel is not a point: reading 1200 pixels as 1200 points gives a sheet 16.67 inches across. Set the resolution instead, and the table shows the page size you will get before you build the file.
300 dpi for anything that will be printed. 96 dpi for screenshots, because that is the CSS reference pixel, so the picture prints the size it was on screen. The table shows the resolution each picture will really print at, which is not the same number when the picture is scaled to fit a page.
No. A JPEG you do not turn is copied into the PDF byte for byte, because a /DCTDecode stream is a JPEG file. A picture you turn, or any other format, is re-encoded, and the tile says so.
Yes, for PNG. The transparent parts stay transparent and the page shows through, which for a PDF means white paper.
Yes. With orientation on Auto each page follows its own picture, and with "the picture's own size" each page is exactly its picture at the resolution you chose. The table lists every page's size before anything is written.
PDF parsing and editing happen in your browser. Documents, and everything inside them, are never uploaded or stored remotely.