JPG to PDF

Turn a group of images into one document with a deliberate page order

JPG to PDF is useful when the source material already exists as images but needs to travel as one document: photographed receipts, scanned forms, whiteboard captures, handwritten notes, product sheets, evidence photos, or pages exported from another application. Instead of sending a folder of separate images, you can arrange them into one PDF whose page sequence has meaning.

SnakTool creates one PDF page for each selected JPG or JPEG. The image list is therefore the document outline: cover.jpg followed by invoice-01.jpg and invoice-02.jpg becomes a three-page PDF in that order. Rearranging the inputs before conversion changes the page order without altering the original image files.

This tool accepts JPG/JPEG inputs only. It does not silently mix PNGs into the same conversion. When a collection contains several image formats, normalize them to the format appropriate for the workflow or use the matching image-to-PDF path.

Input

cover.jpg, receipt-front.jpg, receipt-back.jpg

Method

Arrange them in that order before conversion

Result

A three-page PDF with the cover first, followed by the front and back of the receipt

Each image defines its own PDF page instead of being fitted onto A4

Many image-to-PDF converters ask for A4, Letter, margins, fit or fill. SnakTool's current JPG workflow takes a different approach: the PDF page follows the image's pixel dimensions using a fixed 96 pixels per inch mapping to PDF's 72 points per inch. It does not automatically place every photograph onto a standard paper template.

A 960 × 640 image therefore becomes a 720 × 480 point PDF page. A 640 × 960 image becomes 480 × 720 points. A square image creates a square page. When images have different dimensions or aspect ratios, the resulting PDF can intentionally contain pages with different physical sizes and orientations.

The image is not stretched to fill a differently shaped sheet and is not cropped to force a standard ratio. There is also no automatic margin added around it. The image itself defines the page canvas.

Pixel dimensions become a physical page size through the 96 PPI rule

Pixels do not have an inherent paper size. A 1200-pixel-wide photo can be printed at many widths depending on the chosen pixels-per-inch relationship. To create deterministic PDF geometry, SnakTool interprets image dimensions at 96 pixels per inch and converts that physical size into PDF points at 72 points per inch.

The conversion is 0.75 PDF points per image pixel. A 1200 × 800 JPG therefore creates a 900 × 600 point page. Because 72 points equal one inch, that page is 12.5 × 8.33 inches in PDF geometry. The same rule is applied consistently rather than reading an arbitrary paper-size preset.

This is important when exact print dimensions matter. The tool's fixed mapping determines the PDF page size; it does not promise that camera DPI metadata or another application's preferred print-density tag will control the page dimensions.

Input

1200 × 800 JPG

Method

1200 × 0.75 and 800 × 0.75

Result

900 × 600 PDF points, equivalent to about 12.5 × 8.33 inches

Portrait and landscape images can coexist without being normalized

A phone photo in portrait orientation and a wide screenshot in landscape orientation do not need to be forced into matching pages. Because each JPG creates its own page from its own dimensions, a single PDF can contain portrait, landscape and even square pages.

That is useful for faithful digital packaging, but it can look inconsistent when the document is printed as a conventional report. Printers and PDF viewers may scale pages differently to fit the selected sheet size. If a submission specification demands uniform A4 or Letter pages, the source images need an appropriate layout workflow rather than assuming conversion itself will normalize them.

Review mixed-orientation documents at page transitions. A technically correct PDF can still be awkward to read if a sequence alternates repeatedly between very tall and very wide images.

Camera orientation can be stored outside the JPEG pixels

Phone and camera photos can contain EXIF orientation metadata. An EXIF-aware gallery may display a photograph upright even though the encoded JPEG pixel matrix is stored sideways. That difference becomes important when software embeds the JPEG according to its encoded dimensions rather than first redrawing it through an EXIF-aware image pipeline.

SnakTool's JPG-to-PDF path embeds the JPEG using its encoded dimensions and does not apply EXIF orientation. A photo that looks correct in your phone gallery can therefore appear rotated in the resulting PDF if its apparent orientation depends on that metadata.

Normalize such an image before conversion: rotate it in an image editor that rewrites the pixels into the intended upright orientation, save the corrected JPG, then use that new file. Checking one camera image before converting a large batch can prevent an entire document from being assembled sideways.

Direct JPEG embedding avoids an unnecessary image re-encode

JPEG is already a compressed image format. SnakTool embeds the supplied JPEG bytes into the PDF rather than deliberately decoding every image and saving it through another JPEG quality setting first. The converter therefore does not expose a new 60%, 80% or 90% quality control like the PDF-to-JPG renderer does.

That distinction helps explain what conversion can and cannot improve. A blurry, heavily compressed or low-resolution JPG does not become sharper because it is placed inside a PDF. The PDF is a container for the image; it cannot reconstruct detail that the source photograph no longer contains.

Conversely, if the source JPG already has the visual quality you need, there is no reason for the image-to-PDF step itself to intentionally add another lossy JPEG compression pass. The finished PDF is still a new document container and its total byte size includes PDF structure in addition to the embedded images.

A PDF made from photographs is not automatically searchable

A photograph of a contract may visibly contain hundreds of words, but those letters are pixels inside the JPG. Wrapping that image in a PDF does not create a selectable text layer. Search, copy-and-paste and text selection do not appear merely because the file extension changed from .jpg to .pdf.

Creating a searchable scanned document requires OCR, which analyzes the image and adds recognized text. SnakTool's JPG-to-PDF conversion does not perform OCR. If searchable or editable text is the goal, use an OCR-capable workflow after or instead of simple image packaging.

The distinction also matters for accessibility. A page-sized photograph does not provide the semantic reading structure of a properly authored text PDF. Keep that in mind when the document will be archived, indexed or used with assistive technology.

More images usually mean a larger PDF because conversion is not compression

Combining ten JPGs into one PDF does not make their visual data disappear. The document must still carry the image data for those ten pages plus PDF structure, so a photo-heavy result can remain large even though it is more convenient to manage as one file.

File size depends strongly on the source images. A high-resolution camera photo can contain far more data than a small screenshot, and a batch of large photographs can create a large PDF. If size is the real constraint, resize or deliberately compress the images before conversion, or use an appropriate PDF compression workflow afterward.

Do not reduce image dimensions blindly when small print or document details must remain readable. The useful target is enough source resolution for the intended viewing or printing size, not simply the smallest possible file.

Image metadata and PDF document structure are different layers

A JPG can carry metadata such as camera information, timestamps, GPS-related fields or descriptive tags, while a PDF has its own document-level metadata and structure. Image-to-PDF conversion should not be treated as a metadata-sanitization guarantee merely because the visual page looks the same.

If removing metadata is a privacy requirement, verify that requirement with a dedicated metadata inspection or sanitization workflow rather than assuming a format change automatically strips every possible field. The visible pixels are only one part of what a file can contain.

Likewise, placing an image in a PDF does not create bookmarks, headings, links or form fields from visual elements in the photograph. Those are PDF features that require separate authoring.

Choose image-to-PDF conversion for packaging, not for document reconstruction

JPG to PDF is strongest when the intended result is a faithful sequence of image pages. It can turn photographed paperwork into one shareable file, but it does not rebuild the original Word document, recover fonts, recreate tables as editable objects or infer the structure that existed before the pages became photographs.

That difference helps choose between tools. If the source is already a PDF and you only need to join several documents, Merge PDF avoids converting pages through images. If the source consists of JPGs, image-to-PDF is the direct packaging workflow. If the goal is editable text, OCR or document conversion is a different problem.

Using the closest operation to the actual source preserves more of what you already have and avoids unnecessary format changes.

Browser-local conversion makes device resources part of the limit

SnakTool builds the PDF in the browser rather than uploading the JPG contents to a remote conversion backend. This can be useful for photographed receipts, IDs and other images you would prefer not to send to a third-party processing server.

The tradeoff is that your browser must inspect and embed the images itself. The current policy limits the number of files, image dimensions, pixels per image, estimated memory, processing time and output size; lower-memory devices use tighter limits. Extremely large camera images or large batches can therefore be rejected even when each JPG opens normally on its own.

After conversion, open the PDF and inspect page order, orientation, page dimensions and fine details. Camera photos deserve an orientation check because of EXIF behavior, and print-sensitive documents deserve a page-size check because the converter uses its fixed 96 PPI geometry rather than an A4 or Letter preset.