Turning a folder of scans, receipts or screenshots into one PDF usually means uploading every file to a converter site. The files sit on somebody else's server, and if the service is any good it tells you to delete them afterwards.

There is another route: assemble the PDF inside your own browser tab. I work on OnePassApps, and the Image Studio in our browser app has an Images to PDF tab that does exactly this. But the part that interested me was not the button — it was the output. Because the PDF is assembled locally, you get a real file, and you can open it and check what is actually inside it.

What the panel promises

Open the Image Studio and pick the Images to PDF tab. The empty panel is short and specific:

01 Source No images yet. Drop up to 12 on the stage or browse for them. 02 Pages Page size A4 Orientation Portrait Landscape Image fit Contain Fill page Margins (mm) 03 Result One PDF with a page per image, in the order above.

Four settings, and they decide the whole shape of the document: page size, orientation, image fit, and the margin in millimetres. The page tells you what the two fit modes mean in one sentence — "Contain shows the whole image; fill crops to the page." — and the result step states the contract plainly: "One PDF with a page per image, in the order above."

The source area accepts JPEG, PNG and WebP, with the hint "Up to 12 JPEG, PNG or WebP images · 40 MiB in total" across the whole set. Twelve pages is a deliberate ceiling, and the panel says so up front rather than after the fact.

Running it on real images

I wrote two PNGs to disk — a 640 × 480 gradient-with-grain image (546,750 bytes) and a smaller 320 × 240 one (165,958 bytes) — and dropped both onto the stage.

The first run used the defaults: A4, portrait, Contain, 10 mm margins. The result panel read:

  • "2 ordered pages · valid PDF"
  • File size 598.2 KiB
  • File name probe-pdf-a.pdf (named after the first image)
  • "PDF created in 2.5 s"

and the result card summarised the geometry as "A4 portrait · 10 mm margins · whole image on each page".

Then I switched orientation to Landscape and image fit to Fill page, and ran it again. The card changed to "A4 landscape · 10 mm margins · images fill the page area" and the file shrank to 493.4 KiB.

The page also states the promise that matters: "Processing stays in this browser." — and the whole thing sits under "Nothing leaves this tab."

Checking the PDF's bytes yourself

Both runs produced a blob of type application/pdf. I pulled the bytes out and parsed them directly, because a panel that says "valid PDF" is a claim, not proof.

What the two files actually contain:

run1 (portrait, contain) 612,512 bytes %PDF-1.3 run2 (landscape, fill) 505,266 bytes %PDF-1.3

Both start with %PDF-1.3 and end with a proper %%EOF trailer. Both declare two pages in the page tree (/Count 2), and both really do contain two page objects — not one page with a duplicated image.

The /MediaBox is where the settings show up:

portrait [0 0 595.28 841.89] landscape [0 0 841.89 595.28]

595.28 × 841.89 points is A4 portrait to the decimal — 210 × 297 mm — and the landscape run is the same page turned on its side. So the orientation control really does change the page box, not just rotate the picture inside it.

Contain and Fill are different operations

The clearest proof came from the embedded images. Each page carries one image XObject, and their pixel dimensions changed between the two runs:

portrait / contain 640 × 480 320 × 240 (the source images, untouched) landscape / fill 640 × 439 320 × 219 (cropped)

Under Contain the embedded image is the source image at its own resolution — the whole picture is in the file. Under Fill, 41 rows of pixels come off the top and bottom of the first image and 21 rows off the second.

The interesting detail is the aspect ratio. A full A4 landscape page is 841.89 × 595.28 points, an aspect of 1.4142. But the printable area inside 10 mm margins is 785.20 × 538.58 points, an aspect of 1.4579 — and 640 ÷ 439 = 1.4579. The crop was computed against the margins, not against the raw page box, which is the kind of detail that separates a real layout engine from a resize.

What it does not do

Worth being straight about the edges:

  • Twelve images, 40 MiB. A 200-page scan job is not this tool.
  • The page-size control is a dropdown, and I only exercised one of its options. It offers A4, Letter and Image-sized pages. Both runs above used A4; I did not test the other two.
  • Images only. There is no text layer, no OCR and no way to mix a text page into the set, so the PDF is not searchable.
  • Fill really does crop. That is the documented behaviour and the bytes confirm it, but if the aspect ratios differ it is data you lose. Contain is the safe default when the image is the point.
  • The source images are never touched. The result says "Finished. Download a new copy; the original stays unchanged."
  • The images are stored losslessly. The streams are FlateDecode with DeviceRGB at 8 bits per component, so the file size follows the pixel data rather than a lossy photo codec.

Where it runs

The Image Studio processes in the browser tab: "Processing stays in this browser." and "Nothing leaves this tab." The standard plan is free right now at $0 / month with 100,000 credits every 30 days, no end date set and no card required, and there is no automatic paid subscription.

If you want to try it, the Image Studio is at app.onepassapps.com/studios/image — or read the app guides first: app.onepassapps.com/guides.

One thing I would like to see is a text layer. A PDF of scanned receipts is only useful to most people if you can search it, and right now you get pixels on a page. That is a different problem from the one this tab solves, and this tab does not attempt it.