JPG to PDF Converter Combine photos and scans into one PDF, with the original JPEG data copied across untouched

How to Convert JPG Images to PDF Online for Free

Two minutes. Nothing to install, and no account for a first run. This image to PDF converter runs inside the page you are reading, on your processor rather than ours, which is why your photographs are never sent anywhere: there is no upload step in the code to send them through.

1. 1

   Load your images into the drop zone

   Click the drop zone above or drag your files onto the page. Each file header is read the moment it lands. The card that appears reports the pixel dimensions, the resolution written inside the file, and whether that file can be embedded untouched. Anything that has to be rewritten says so before you spend an operation on it.

2. 2

   Set the page order

   Page order follows the cards on screen. Drag a card to move it, or press Sort A-Z. The sorter reads the digits inside a filename as a number, so IMG_2 lands ahead of IMG_10 rather than after it, which is the difference between a scanned contract and a shuffled one.

3. 3

   Choose how pixels become paper

   Pick a fixed sheet such as A4 and every image is scaled to fit inside it. Pick Fit to image and the page is built to the physical size the file claims through its own resolution tag. Then set the margin and the orientation. Both controls behave differently under the two sizing modes, which the page size section below works through.

4. 4

   Convert, then check the scale against a ruler

   Press Convert to PDF. Your processor builds the document from there. Before a long batch of scans goes anywhere near a printer, open page one at exactly 100 percent zoom and hold a ruler against the paper. Sixty seconds of checking beats reprinting four hundred pages.

Turn off Merge all images into one PDF and you get one document per image, listed separately on the result screen. Each photograph becomes its own record. That suits a stack of delivery receipts filed under different reference numbers, and it is exactly wrong for a catalog or a presentation, where the whole point is that every page arrives in one file.

The Engineering Behind Image to PDF Conversion

A PDF has no general purpose image format. It carries pictures through a short list of stream filters, and two of those decide everything that happens on this page. DCTDecode holds JPEG data, which means a PDF can swallow a JPEG bitstream whole and leave the decoding to whatever program opens the document. FlateDecode holds deflate-compressed samples, the same algorithm PNG uses. Every photograph your phone or your DSLR produces has to end up inside one of those two before it can sit on a page.

That constraint leaves three routes through the converter. The file card names the one your image took, so read it before you press convert.

• A baseline JPEG goes through untouched. The compressed bitstream is written into the PDF as a DCTDecode stream without being decoded first. Nothing is re-encoded and nothing is rounded off. Run the same photograph through this tool a thousand times and the thousandth document holds the same pixel data as the first, wrapped in a few hundred bytes of structure.
• A PNG is repacked without losing a pixel. PNG cannot take the passthrough route, because its rows carry prediction filters that a PDF image stream does not understand. The engine decodes it to raw samples, deflates those samples again as a FlateDecode stream, and writes the alpha channel out separately as a soft mask. Every sample value survives. The byte count can move either way, depending on how well the original PNG encoder did its job.
• Everything else is rewritten exactly once. WebP, AVIF, GIF, BMP, HEIC and the awkward JPEG variants are decoded by the browser and encoded again in a single pass. Where they land depends on what they are: a GIF or a BMP is written as a lossless PNG, because that material is usually flat artwork a photographic codec would smear, while an already-lossy photograph goes to JPEG at quality 0.92. The card prints the reason it chose.

The JPEG variants that break the passthrough route

A .jpg extension promises nothing. This is where generic convert to PDF tools fail quietly, handing you a document that renders correctly in Chrome and shows a black rectangle in Adobe Acrobat. Our engine reads the bytes rather than the extension. The problem surfaces on the file card, before your client ever sees it.

Detection reads the raw header in memory rather than trusting the file extension or the MIME type your operating system reports, because both of those are wrong often enough to matter. The engine walks the JPEG marker chain to find the frame header, the component count and the density block. PNG headers are checked for bit depth and the interlace flag. That probe costs under a millisecond. It is also the reason the finished document opens in Acrobat, in Preview and on a twelve year old print controller alike.

DPI, Page Size, and Why Your Scans Print at the Wrong Scale

A PDF measures the page in points, and a point is exactly 1/72 of an inch. An image measures itself in pixels and nothing else. Turning one into the other needs a resolution figure, and when the file carries none the engine has to assume a value, which is the single most common reason a scan comes out of a printer at the wrong physical size.

The arithmetic is unforgiving. An image 2480 pixels wide at 300 dpi measures 8.27 inches across, and at 72 points to the inch that comes to 595 points, which is the width of an A4 sheet almost exactly. Hand those same 2480 pixels to a converter that assumes 96 dpi and the page comes out 25.8 inches wide. Same file, same pixels, a sheet nearly a meter across, all because one four byte field was never written by the software that exported it.

Where the resolution actually lives

Cameras and scanners write resolution into more than one place, and they do not always agree with each other. The engine reads all three:

• The JFIF density block. An APP0 segment near the start of the JPEG. It holds a units flag plus an X and Y density. A units flag of 1 means dots per inch, 2 means dots per centimeter, and 0 means the numbers are only an aspect ratio with no physical size attached to them at all.
• The EXIF XResolution tag. A TIFF structured block inside an APP1 segment, with its own byte order and its own resolution unit. It is read as the fallback when the JFIF block is missing or filled with zeros.
• The PNG pHYs chunk. Physical pixel size in pixels per meter, so multiply by 0.0254 to get dpi. Most export tools never write it, which is why screenshots and design tool exports arrive with no idea how large they were meant to be.

Whatever the file states, the card shows it. When nothing in the batch carries a resolution at all, the engine falls back to 96 dpi, the old screen standard and the safest guess for an image that was never intended for paper. The Assumed resolution control overrides that guess, which is what you want when a scan arrived through an email client that stripped the header on the way.

Two ways to size the page

Orientation behaves differently under each mode. With a fixed page size, Match image gives a wide picture a landscape sheet and a tall one a portrait sheet. Under Fit to image, forcing an orientation stretches the sheet rather than turning the artwork, which is deliberate, because a photograph should never end up silently rotated onto its side. A phone photograph is a separate case: the sensor stores a landscape frame plus an orientation tag, and the engine honors that tag by rotating the coordinate system the image is painted into, so the page comes out upright without re-encoding a single sample.

Compression Ratios and the Reality of Generation Loss

A PDF built this way is your images plus a thin layer of document structure. Ten photographs totaling 24 MB give you a PDF a little over 24 MB, because the passthrough route never runs a second compression pass over them. A converter that hands back a dramatically smaller file has recompressed your images, and the quality it removed is not recoverable. That trade can be the right one. You should be the one making it.

JPEG compression throws data away, and the loss compounds. The encoder cuts the image into 8x8 blocks, converts each block into frequency coefficients, divides those by a quantization table and rounds the result. Rounding is where the detail dies. Decode and encode the same picture again and you are quantizing numbers that were already quantized once, so the errors stack and ringing appears along every hard edge. On a photograph, a second pass at quality 0.92 is invisible; on a scan of small print it is the difference between readable and not.

• Passthrough costs nothing. The bitstream in your JPEG is the bitstream in the PDF. Convert the same file a thousand times over and the thousandth document holds the same pixel data as the first one did.
• The PNG repack costs nothing either. The container changes, the samples do not. File size can move up or down depending on how efficient the original PNG encoder was.
• The rewrite costs exactly one generation. One decode, one encode, no more than that. Flat artwork such as a GIF or a BMP is written as a lossless PNG, so nothing is lost at all, while an already-lossy photograph goes to JPEG at quality 0.92. The card says which, and why.

When the output is too big to send

The fix for a bloated PDF is in the source images, not in the converter. Twelve raw 12 megapixel phone photographs make a document that a corporate mail server bounces on sight. Resize the sources before they go into the queue. An A4 page scanned at 300 dpi needs roughly 2480 by 3508 pixels and no more than that. Past that point you are storing the texture of the paper at archive resolution, and paying for it in megabytes on every single send.

What Actually Converts, Including Hostile Formats

The conversion runs in your browser, so the list of formats that work is the list your browser can decode. That is a hard limit and we do not pretend otherwise. A file that converts on a current Chrome build can fail on a locked down office machine that has not been updated in four years.

Transparency needs a compromise, and which one you get depends on the route. A PDF carries per-pixel opacity as a soft mask, a second greyscale image attached to the first, so a PNG with an alpha channel keeps its transparency exactly. On the JPEG rewrite route there is no alpha to keep, because the JPEG format has nowhere to store it. Those pixels are flattened onto white. White rather than black is a deliberate choice: flattening onto black turns a company logo into a solid rectangle on a printed page, and that mistake always gets found by the client rather than by you.

Zero-Trust Architecture: Your Files Never Reach Our Servers

The usual build for an online JPG to PDF converter is an upload form, a queue on a server somewhere, a command line tool doing the work, and a temporary download link handed back to you. Your photographs crossed the internet, landed on a disk you have no access to, and stay there until a cleanup script decides otherwise. For holiday pictures that is fine. For a passport scan, a signed contract, a patient record or a prototype under NDA, you have just made an undocumented data transfer that nobody logged.

This tool has no upload endpoint, because the server step does not exist anywhere in the code. Files come in through the browser File API, get probed and embedded by a JavaScript PDF library running on your own processor, and come back out as a Blob your browser downloads from itself. The images never leave your machine.

Verify it in thirty seconds

1. Open developer tools, go to the Network panel, and clear the log.
2. Convert a heavy batch and watch the requests arrive.
3. The engine scripts load once, then a small JSON request records that a conversion happened. No request carries an image payload, and nothing outbound is anywhere near the size of your batch.
4. The proof that settles it: load the page, disconnect the machine from the network, and convert. It works. A cloud converter cannot.

Metadata deserves a precise answer, because it depends on which route your file took. On the rewrite route it is genuinely gone, since the new image is built from decoded pixels and carries nothing else. On the passthrough route the JPEG is embedded exactly as it arrived, which is the entire point of passthrough, and its EXIF block travels inside the image stream along with it. No PDF reader surfaces that block. The bytes are still in the file, so treat them as readable. If a photograph has to reach a client without the GPS coordinates your phone stamped into it, strip the EXIF at the source or export a fresh copy from your photo app before you convert.

Batch Limits, and What Happens When You Hit Them

A dozen receipts or a handful of ID scans is nothing, and the free engine handles that without complaint. Push fifty high resolution photographs into the queue and you meet a different limit: the browser holds every decoded image in memory uncompressed, and the tab runs out of room before the document is finished. One 12 megapixel photo occupies roughly 48 MB of RAM no matter how small the JPEG is on disk.

Anonymous visitors get one operation every 12 hours. A free CartHacker account doubles that to two, and both tiers cap a batch at 20 files or 100 MB, whichever comes first. CartHacker Premium drops the operation counter and raises the batch ceiling to 100 files and 500 MB. That is the setting for a scanned archive rather than a stack of receipts.

When a Conversion Fails, and How to Fix It

Every file is probed as it lands, so a fatal problem shows up on the card before you spend an operation on a batch that was never going to work.

Before a long scan batch goes to the printer

1. Convert two pages first, not the whole archive.
2. Open the result at exactly 100 percent zoom and check it against a ruler.
3. Send one page to the office printer and measure what comes out of it.
4. Run the full batch only once the scale checks out. A dpi mistake caught on page two costs a minute; the same mistake found on page four hundred costs the reprint.

Frequently Asked Questions

The rest of the PDF suite

All of these run the same way: your file is read by JavaScript on your own machine, the work happens on your processor, and the result is handed back to you as a download that never existed anywhere else.