JPG to PDF Converter
Turns JPG and PNG files into a PDF in your browser, one image a page, and says what each page will print at before you download it.
This tool needs JavaScript: the pictures are read, re-encoded and written into a PDF by your browser, which is why nothing is uploaded.
Choose image to make every page exactly the size of its picture, which is what you want for scans and screenshots.
Auto turns the page for a wide image and leaves it upright for a tall one.
Contain fits the whole image inside the margin. Actual never enlarges a small image. Fill covers the page and crops nothing, so part of the image can run off the edge.
72 points is an inch. Ignored when the page is the image.
A pixel has no physical size, so something has to decide how large the image is in inches. 96 is the screen convention, 300 is print.
Every page is stored as JPEG, which is the format a PDF can hold without re-encoding. Lower means a smaller file and visible artefacts around text.
Reading the pictures…
No pages yet. Every picture becomes one page, in the order you add them.
Every free “JPG to PDF” site asks you to upload the pictures first. That is the wrong shape for the job: the files people convert are passport scans, signed contracts, receipts and photographs of documents, and none of those should be sitting on somebody else’s server for the sake of a page size.
This does it in the browser. The pictures are decoded, re-encoded as JPEG and written into a PDF on your own machine, and the network is never involved. It also tells you the one thing these converters never mention: what each page will actually print at.
How to use
- Choose pictures, or drop them on the box. Each one becomes a page, in the order you add them.
- Reorder with the arrows, remove with the cross.
- Pick a page size. Choose “image” to make every page exactly the size of its picture, which is what scans and screenshots want.
- Check the pixels-an-inch figure on each row before downloading.
Example
Three phone photographs of a contract, on A4 with a half-inch margin:
1. contract-p1.jpg
3024 × 4032px · page 595 × 842pt · 405 ppi printed · 1.4 MB
2. contract-p2.jpg
3024 × 4032px · page 595 × 842pt · 405 ppi printed · 1.3 MB
3. signature.png
900 × 300px · page 842 × 595pt · 94 ppi printed · 61 KB
At this size it prints at 94 pixels an inch, which looks soft on paper.
3 pages · 2.8 MB · A4The third row is the useful one. That page will look fine on screen and blurry when printed, and knowing that before you send the file is the difference between one email and three.
Pitfalls
A pixel has no physical size. An image is 3024 pixels wide; whether that is four inches or thirty depends on the density you claim for it. That assumption is a field here rather than a hidden constant, and it is the reason the same photograph can come out sharp on one converter and soft on another.
Under about 150 pixels an inch, print looks soft. Screens are happy at 96; a printer wants 300. The warning on a row is not an error, it is a statement about paper, and it does not apply if the PDF is only ever going to be read on a screen.
Every page is stored as JPEG. PDF can carry a JPEG without touching it, which is why this is fast and why the output is roughly the size of the pictures. A PNG screenshot of text re-encoded as JPEG picks up ringing around the letters, so keep the quality high for anything with type in it, or keep the PNG and use a screenshot tool that writes PDF directly.
Transparency becomes white. JPEG has no alpha channel, so a transparent PNG is flattened onto white before encoding. A logo designed for a dark background will come out wrong, and the fix is to flatten it yourself onto the colour you meant.
Fill crops nothing but it does overflow. Contain fits the whole picture inside the margin; fill covers the page, which means parts of a picture with a different aspect ratio run off the edge. Actual size never enlarges, which is what you want for a small scan you do not wish to see interpolated.
HEIC files from an iPhone will not open here. Browsers cannot decode them without a library, so the photograph has to be exported as JPEG first. iOS does this automatically when you share rather than airdrop the original.
The order is the order you added them in, not the order of the filenames. Choosing 20 files at once gives you whatever order the file picker hands over, which on some systems is alphabetical and on others is not. Check the numbering before downloading.
Scanned text is better served by a scanner. This makes a PDF of pictures, so the result has no selectable text and no OCR. It cannot be searched, and a screen reader gets nothing from it.
Compatibility
Works in any current browser with a canvas, which is all of them since about 2012. Nothing is uploaded, nothing is stored, and closing the tab discards everything.
The PDF is written by hand, in about 200 lines. A file like this is a catalog, a page tree, one page and one image object per picture, and a cross-reference table of byte offsets at the end. The offsets are the part that has to be exact, because a wrong one produces a file that opens in some readers and not others, so they are recorded as the bytes are appended rather than calculated afterwards, and the test suite follows every offset in the table to check it lands on its object. The output was opened in macOS Preview to confirm it parses and renders, not only that it passes its own tests.
Image data is copied in untouched under /DCTDecode, which is PDF’s way of saying “this stream is a
JPEG”. That is why a 12 megapixel photograph does not have to be re-encoded twice and why the file size
is predictable.
Changing the quality re-encodes from the original file rather than from the JPEG already made, so moving the slider up and down does not stack compression artefacts.
Sixty pages is the limit, and 30MB a picture. Both are about how much decoded image data a browser tab should be asked to hold at once rather than about the format.