DEV Community: Anuj Kabra

Your photo knows where you took it: stripping EXIF before you post

Anuj Kabra — Fri, 06 Nov 2026 04:22:21 +0000

A JPEG can carry more than pixels. Phones and cameras often embed EXIF metadata: when the shot was taken, which device took it, exposure settings, and sometimes the exact GPS coordinates. That location tag is useful in your own library. It is less useful on a photo you email, upload to a form, or post publicly. Below are built-in ways to stop location leaving with the file, a command-line check that shows what is still there, and one gotcha: scrubbing metadata can also drop the capture date, which matters if the photo is evidence.

I checked the share and remove steps against Apple's Personal Safety guide (published September 2026) and current Windows File Explorer docs, and I verified the ExifTool commands on a small test JPEG I tagged with dummy GPS coordinates (ExifTool 13.30).

What is usually in the file

EXIF is a block of tags stored with the image. Common ones:

When: DateTimeOriginal and related date fields
What took it: camera or phone make and model
How: aperture, shutter, ISO, lens
Where: GPS latitude, longitude, altitude, and related GPS tags

Not every photo has GPS. Location only gets written if the camera app was allowed to use Location Services (or the equivalent on Android). The rest of the EXIF block can still be present without coordinates.

To see what a file is carrying, ExifTool is the clearest check I know:

exiftool -GPS:all photo.jpg
exiftool -DateTimeOriginal -Make -Model photo.jpg

On my test file, -GPS:all printed latitude 28.6139, longitude 77.209, altitude, and the N/E refs. After stripping GPS (next section), that same command printed nothing for GPS while Make, Model and DateTimeOriginal were still there.

iPhone: leave location out of the shared copy

Apple's guide covers two different jobs: exclude location from one share, or remove it from the photo in your library.

For one share (outgoing copy only):

Open the photo in Photos (or select it from Camera's roll).
Tap Share, then tap Options.
Turn Location off. The sheet should show Location Not Included above Options.
Choose Mail, Messages, AirDrop, Files, or whatever destination you want.

That does not rewrite the original in your library. It only controls what goes out with that share. Apple's iPhone share guide also notes that sharing a photo can include date, device and captions unless you adjust Options; turning Location off is specifically about the GPS metadata.

To remove location from the photo itself:

Open the photo, tap the info / More control.
Tap Adjust Info, then Adjust Location, then No Location.

To stop Camera writing location on new shots: Settings > Privacy & Security > Location Services > Camera > Never. That does not clean photos you already took.

Windows: Remove Properties and Personal Information

File Explorer can strip metadata without installing anything:

Right-click the image and open Properties.
Open the Details tab.
Click Remove Properties and Personal Information at the bottom.
Prefer Create a copy with all possible properties removed so the original stays intact. Or choose specific properties (GPS among them) if you only want some gone.
Click OK, then share the copy.

You can confirm afterward on the Details tab: a GPS section should be gone if location was present.

macOS: honest limits

macOS does not give you one "strip all EXIF" button the way Windows does.

Preview (location only): open the image in Preview, choose Tools > Show Inspector (Cmd+I), open the GPS tab if it appears, click Remove Location Info, then save. No GPS tab means there was no location to remove. Camera model, exposure and capture time stay in the file.

Photos app: Image > Location > Hide Location is a library flag; Apple's own Personal Safety page pairs it with Revert to Original Location, so do not treat Hide as destroying the coordinates in the file. When you export, use File > Export > Export Photos and untick Include Location Information. That affects the exported copy's GPS. Camera model and timestamps can still travel with the export. Dragging a photo out of Photos, or Export Unmodified Original, keeps the embedded metadata.

For a full scrub on a Mac, use ExifTool (next section) on a copy of the file.

Command line: strip GPS, or strip everything

ExifTool (exiftool.org) reads and writes EXIF. Install it from the site or your package manager, then work on a copy.

Location only (keeps dates and camera tags):

exiftool -gps:all= photo.jpg

By default ExifTool keeps a photo.jpg_original backup. To rewrite in place after you have checked the result:

exiftool -gps:all= -overwrite_original photo.jpg

Everything ExifTool can clear (dates, camera model, GPS, and more):

exiftool -all= photo.jpg

On my test JPEG, -gps:all= removed every GPS tag while DateTimeOriginal, Make and Model remained. -all= left only basic JPEG file info: no GPS, no capture date, no camera model.

Read after you write:

exiftool -GPS:all photo.jpg
exiftool -DateTimeOriginal -Make -Model photo.jpg

The gotcha: capture date goes with a full scrub

If you need the photo as evidence of when something happened, do not run -all= and do not re-encode through a path that drops all metadata, unless you have the original stored elsewhere. GPS is the privacy problem for most sharing. Capture time is often the thing you still want for yourself.

Some websites strip EXIF on upload. Some do not. Relying on the destination is guessing; cleaning the copy you send is something you can verify.

Browser re-encode drops EXIF as a side effect

Any path that decodes the image to raw pixels and encodes a new JPEG keeps the picture and leaves the EXIF block behind. That is how HTML canvas export behaves, and it is what a local image compressor that redraws through a canvas is doing.

I built ToolOcean. Its compressor page says the image is decoded, drawn onto a canvas, and encoded again as JPEG at the quality you set, with nothing uploaded, and that metadata is not preserved: camera settings, timestamps and GPS do not survive. I did not drive that live UI for this post. I did decode and re-encode my GPS-tagged test JPEG with Pillow the same way a canvas pass would, and ExifTool afterward showed no GPS, no DateTimeOriginal, no Make or Model. Same trade-off the page warns about: convenient for privacy, inconvenient if you needed the capture date.

The page accepts JPG, PNG and WebP; the download is always JPEG. Quality around 80 is what it suggests for photographs. The tool is at toolocean.co/image-compressor. The built-in and ExifTool steps above work whether you use that page or not.

Drafted with AI help, tested and checked by me.

How I check whether a "no upload" PDF tool really keeps my file local

Anuj Kabra — Wed, 04 Nov 2026 04:31:47 +0000

Lots of PDF and image sites now say "your file never leaves your device". Some of them mean it, and some run the work on a server anyway. You don't have to take the label on trust: the browser can show you every request a page makes, and you can cut the network and see whether the tool still works. Below are the exact steps in Chrome or Edge (Firefox where it differs), what each check can and can't prove, and one trap with the obvious "look for a big request" approach. I checked the DevTools labels in Chrome 156 and against the Chrome and Firefox DevTools docs, and I ran the checks on a small test page of my own that does upload a file, to see what a real upload looks like.

Check 1: watch the Network panel while the tool runs

Open the tool's page, but don't pick a file yet.
Open DevTools (F12, or Ctrl+Shift+I; Cmd+Option+I on a Mac) and click the Network tab. DevTools only records requests while it's open, so open it before you pick the file.
Tick Keep log. Older Chrome versions call it Preserve log. Without it the list is wiped if the page navigates, which is exactly when a "processing..." page might send your file.
Click Clear (the circle with a line through it) so the list only holds what happens next.
Now pick your file, run the tool, and wait until the download has finished. Then wait a bit longer before you read the list.

What to look for is any request that sends data out: method POST or PUT. Type method:POST in the Filter box to show only those (I checked that this filter works), or right-click a column header and add the Method column. Fetch/XHR in the type buttons is another useful view, since uploads from scripts usually show up there.

Click a suspicious request and look at:

Headers: Request URL tells you where it went, and Request Method confirms it's a POST.
Payload: a normal form upload shows up here. On my test page, a file sent as form data appeared under "Form data" as file (binary).
Initiator: which script started it.

The trap: the Size column is about the download

The obvious advice is "look for a request the size of your file". The Size column won't show it. Chrome's docs define Size as "the combined size of the response headers plus the response body, as delivered by the server", which is the download, not what was sent. On my test page, a 509,728-byte PDF uploaded with fetch showed up as 0.1 kB in the Size column, because the server only answered "ok". The status bar said "96 B transferred".

The size filter has the same problem. larger-than:100k hid that half-megabyte upload completely. So don't filter by size to find uploads; filter by method, then open each POST and see what's in it. In my test, the request that sent the file as a raw blob had no Payload tab at all. The Headers tab only showed "Provisional headers are shown" with Content-Type: application/pdf, which was enough to give it away.

The gotcha: workers and delays

An upload doesn't have to happen when you click the button, and it doesn't have to come from the page's main script. My test page hands the file to a Web Worker, which waits 3 seconds and then POSTs it. Chrome still listed it in the same Network panel, with a small gear icon in front of the name and worker.js:1 as the Initiator. But it only appeared 3 seconds after I picked the file. If I'd closed DevTools when the download finished, or cleared the list, I'd have missed it. Keep the panel open until well after the result is saved, and look again before you close the tab.

Firefox

The Network tab works the same way, with different names. The setting that keeps the log is Persist Logs, in the toolbar's menu of other actions (the docs also call it "Enable persistent logs" in Settings). The type buttons have XHR instead of Fetch/XHR. method:post works in the filter box. When you click a request, what was sent is in the Request tab rather than "Payload". The docs describe the Transferred and Size columns in terms of the resource being loaded, so I'd expect the same trap there. I didn't run the upload test in Firefox.

Check 2: cut the network after the page has loaded

A tool that really runs locally doesn't need the network once its code has loaded.

Load the page and wait until it's fully ready.
Go offline. In Chrome DevTools, open the throttling drop-down next to "Disable cache" (it says No throttling) and choose Offline. In Firefox it's the Throttling drop-down, which also has Offline. Or just turn off Wi-Fi or unplug the cable, which takes the whole machine offline rather than one tab.
Pick the file and run the tool.

If it finishes and you get a working file, the work happened on your machine. If it hangs or shows a network error, it needs a server.

What these checks can't prove

Both checks show what happened while you were watching, on that one visit. Neither one can show:

Later sending. A page can keep the file in the browser's storage and send it when you're back online or on your next visit. The offline test only proves the tool doesn't need the network to work.
Small pieces. A file can be split into many small requests, or the page can send something derived from it (extracted text, a thumbnail), which would be much smaller than the file. That's why you open each POST instead of looking for one big one.
Encoding. Base64 makes data about a third bigger and it can be wrapped in JSON, so the body won't look like a PDF.
WebSockets. A WebSocket connection shows up as one entry; what's sent over it is under that entry's Messages tab (Chrome lists up to the last 100 messages, with a Length column). Click the Socket button (older versions say WS) to find these.
Anything outside the tab. DevTools shows that tab's traffic. A browser extension, another tab, or a desktop app isn't in that list. Chrome's chrome://net-export page records the whole browser's network activity to a file while that page stays open; reading the file needs Chromium's netlog viewer, so it's more work, but it doesn't depend on which tab's DevTools you had open.

And they can't tell you what the site's code will do next week. A tool that's local today can change. If a file is sensitive enough that this matters, an offline command-line tool avoids the question. For merging, qpdf does it in one line (I used qpdf 12.4.2):

qpdf --empty --pages first.pdf second.pdf -- merged.pdf

What I saw on my own merge tool

I built ToolOcean, so I ran both checks on its merge page as well, with two dummy PDFs I generated (509,728 and 151,787 bytes; 2 pages and 1 page). I used headless Chrome driven by Playwright, logging every request with its method, host and request body size, and searching each body for chunks of either file, raw and base64 encoded.

Loading the page made about 110 requests, almost all GETs to the site itself for its own code and fonts, plus a Google Tag Manager script and three small analytics POSTs (272 to 289 bytes) to gateway.umami.is.
From picking the files through to the download, and for 20 seconds after it, there was one request: a 357-byte POST to gateway.umami.is. Its body is JSON recording a "tool-run" event for "pdf-merge", with the page URL, screen size and language. No file names and no file content.
No request body contained any part of either PDF. The merged file was 3 pages, 659,579 bytes, with both files' text in order.
With the browser set offline after the page had loaded, the merge still finished and saved a 3-page file of the same size. The only failure was that analytics ping, which errored with ERR_INTERNET_DISCONNECTED.

The tool itself is at toolocean.co/merge-pdf-without-uploading. The checks above are the same ones I'd run on anyone else's.

Drafted with AI help, tested and checked by me.

The portal wants a JPG of my PDF certificate

Anuj Kabra — Tue, 03 Nov 2026 04:25:58 +0000

Plenty of upload forms take a certificate only as a JPG, usually with a size limit like "under 200 KB" and sometimes a maximum width in pixels. The PDF you have doesn't have pixels at all: its text is drawn from outlines, so when you turn it into a JPG you choose how many pixels each inch of paper gets. That one number decides whether the small print survives, and the KB limit is a separate step after it. I tested everything below on a dummy A4 certificate I generated with fake details: a big heading, a name, a 9 pt certificate number, 6 and 7 pt small print, a seal, and a pale wavy background pattern like the security print many certificates have.

Pixels come from the resolution you render at

A PDF page has a size in inches (A4 is 8.27 x 11.69 in), so the pixel size of the image is just inches x DPI:

DPI    A4 in pixels    6 pt type in pixels
72     596 x 842       6
96     794 x 1123      8
150    1241 x 1754     12.5
200    1654 x 2339     17
300    2481 x 3508     25

The pixel sizes are what pdftoppm actually wrote for my A4 page (it rounds up, so 1241 rather than 1240). The last column is points / 72 x DPI, the font size in pixels; capital letters are only about two thirds of that. A screenshot of a whole A4 page on a 1080p screen can't be more than about 1080 px tall, which is under 100 DPI. At 72 DPI, which is what a viewer's "1x" export gives, the "8" and the "B" in my 6 pt serial number were grey smudges that looked alike. At 96 they were readable if I squinted, and at 150 they were clean.

The command line: pdftoppm

pdftoppm comes with poppler (poppler-utils on Linux, brew install poppler on a Mac). I used version 25.03.0.

pdftoppm -r 200 -jpeg -jpegopt quality=85 -singlefile certificate.pdf certificate

-r is the DPI, -jpegopt quality= sets the JPEG quality (without it, my files came out at quality 75), and -singlefile writes certificate.jpg instead of certificate-1.jpg. For one page out of a longer file, add -f 2 -l 2 for page 2. It also writes the DPI into the JPEG header, so the 200 DPI file reports 200 x 200 if a form checks that field.

If the form gives a pixel size instead of a DPI, let pdftoppm work out the scale:

pdftoppm -scale-to-x 1000 -scale-to-y -1 -jpeg -singlefile certificate.pdf certificate

That gave me 1000 x 1415; -1 keeps the proportions.

macOS Preview

Open the PDF, select the page, then File > Export (not Export as PDF), set Format to JPEG, type a Resolution, and use the Quality slider. Export writes only the selected page. I ran my tests on Linux, so I haven't clicked through Preview for this post; check the pixel size of what it saves before uploading.

Then the KB limit

Here's what my dummy certificate came to at the default quality 75:

                         150 DPI    200 DPI    300 DPI
with background pattern  386,593    537,605    965,995 bytes
plain white background   127,690    192,847    351,011 bytes

The text barely costs anything. The fine wavy background is what fills the file, and converting to grayscale didn't fix that: -gray at 150 DPI only went from 386,593 to 383,104 bytes.

So to get under 200 KB there are two dials, pixels and quality, and the order matters. I pushed my 300 DPI render to 200 KB without reducing pixels, and ImageMagick had to go down to quality 8: the text still read fine, but the cream background broke into patchy white blocks. Reducing to 1240 px wide first, the same 200 KB came out at quality 47 and looked like the original at normal zoom. For 100 KB, 1000 px wide landed at quality 30 while 1240 px needed 17, with visible smudges around the letters.

With ImageMagick (version 7, the command is magick; on version 6 it's convert), render a lossless PNG once, then resize and let ImageMagick find the quality:

pdftoppm -r 300 -png -singlefile certificate.pdf certificate-300
magick certificate-300.png -resize 1240x -define jpeg:extent=200kb upload.jpg

-resize 1240x sets the width and keeps the proportions, and jpeg:extent searches for the highest quality that fits. My result was 194,735 bytes at 1240 x 1753. Starting from the PNG instead of a JPEG avoids compressing twice.

With poppler only, a small loop does the same search by hand:

limit=200000
for q in 90 85 80 75 70 65 60 55 50 45 40; do
  pdftoppm -r 120 -jpeg -jpegopt quality=$q -singlefile certificate.pdf upload
  size=$(stat -c %s upload.jpg)   # macOS: stat -f %z upload.jpg
  echo "quality $q: $size bytes"
  [ "$size" -le "$limit" ] && break
done

At 150 DPI my patterned certificate was still 221,594 bytes at quality 40, so I dropped to 120 DPI, which stopped at quality 60 with 195,945 bytes. If even that isn't enough, lower -r again rather than the quality.

The gotcha: don't start from screen resolution

The usual advice is "render higher and scale down", and the part of it that matters is the first half. When I compared a page rendered directly at 1000 px wide with one rendered at 300 DPI and then resized to 1000 px, I couldn't see a difference in the small print; pdftoppm smooths edges as it renders. What does ruin small print is starting from too few pixels: a screenshot, or a viewer export at 72 DPI, can't be fixed by enlarging it later, because the detail was never captured. So render at 200 or 300 DPI, keep that file, and come down only as far as the form's pixel and KB limits make you. Before uploading, open the JPG at 100% and read the smallest line, usually the certificate number or the verification code.

A browser option

I built ToolOcean, and its PDF to images page renders pages in the browser without uploading the file. It offers PNG or JPEG and three scales, 1x, 2x and 4x, which the page describes as 72, 144 and 288 DPI. PNG is selected by default, so switch it to JPEG for an upload form. On my dummy certificate the JPEGs came out at 595 x 841 (105,487 bytes), 1190 x 1683 (439,103 bytes) and 2381 x 3367 (1,247,072 bytes), downloaded as a ZIP; each page also has its own Download button. Two things to know: it has no quality or KB setting, so you'll still need one of the steps above to get under a limit, and its JPEGs say 72 DPI in the header at every scale even though the pixels match the scale you picked. The page says it can't open password-protected PDFs. After I picked the file, the only network requests were the page's own renderer script and fonts and a 340-byte analytics ping: toolocean.co/pdf-to-images.

Drafted with AI help, tested and checked by me.

Send only the pages they asked for: splitting a PDF before you share it

Anuj Kabra — Mon, 02 Nov 2026 04:27:23 +0000

When someone asks for "page 3 of your statement" or "the discharge summary", the easy thing is to send the whole PDF. That hands over every other page too: other transactions, other diagnoses, an address, an account number. Cutting the file down to the pages they asked for takes a minute, and there's one detail that catches people out: some ways of doing it keep data from the pages you removed. I tested everything below on a dummy 8-page bank statement I generated with fake numbers (title, author and an account number in its metadata, one bookmark per page).

The built-in routes

You probably already have something that can do this.

macOS Preview: View > Thumbnails, select the pages you want (Cmd-click for several), and drag them onto the desktop. Preview makes a new PDF from just those pages. Another way is File > Print, set the page range, then PDF > Save as PDF at the bottom left.
Chrome or Edge, any OS: open the PDF in the browser, Print, choose "Save as PDF" (Chrome) or "Microsoft Print to PDF" (Edge on Windows) as the printer, set Pages to Custom and type something like 3-4 or 2,5.
Acrobat Reader: the free Reader can't extract pages itself, but its Print dialog with "Microsoft Print to PDF" or the Mac "Save as PDF" does the same job.

I ran the tests on Linux, so I haven't clicked through these apps for this post. The print routes write the pages out again through the printing system rather than copying them, so check the result: zoom in on small print, and see if the text can still be selected if that matters to whoever's receiving it.

The command line: qpdf

qpdf copies pages without re-rendering them, so text, fonts and images stay exactly as they were. I used qpdf 12.4.2.

qpdf --empty --pages statement.pdf 3-4 -- pages-3-4.pdf

--empty starts from a blank document, --pages names the input and the range, and -- ends the page list. The range syntax is worth knowing:

3-4        pages 3 and 4
2,5        page 2 then page 5, in the order you type them
7-z        page 7 to the last page (z is the last page)
r2-r1      the last two pages, counted from the end
1-z,x5     every page except 5

I checked each one by pulling the text back out of the result with pdftotext and looking for a marker I'd printed on every page. 1-z,x5 and 1-4,6-8 both gave the same 7 pages, and 5,2 really did put page 5 first.

The gotcha: what comes along from the original

qpdf's own help (qpdf --help=page-selection) starts with a form that uses an input file as the base instead of --empty, and says "Document-level information, such as outlines, tags, etc., is taken from in.pdf and is preserved in out.pdf." Here's what that means in practice:

qpdf statement.pdf --pages . 3-4 -- pages-3-4.pdf

The . means "the main input file". This gives the same two pages, but it keeps what belongs to the document rather than to a page. Here's what each output carried, from pdfinfo and a count of bookmark entries with pypdf:

                         pages  Title / Author / Subject    bookmarks
original                   8    yes (incl. account number)      8
qpdf ... --pages . 3-4     2    yes, all kept                   8
qpdf --empty --pages 3-4   2    none                            0
pdfseparate + pdfunite     2    none                            0

So the two-page file from the . form still had the account number in its Subject field and all eight bookmarks, which name pages that aren't in it anymore. In a real statement, bookmark titles and metadata can say a lot. Use --empty when the point is sharing less, and check with:

pdfinfo pages-3-4.pdf

and look at the bookmarks pane in your viewer. pdfinfo only shows the info dictionary; there can also be XMP metadata, which exiftool -a -G1 file.pdf lists.

One more thing to check before sending: a split never changes what's printed on the pages you keep. If page 3 has your full account number in its header, so does the extract.

Poppler, if that's what you have

pdfseparate writes one file per page, and pdfunite joins them:

pdfseparate -f 3 -l 4 statement.pdf page-%d.pdf
pdfunite page-3.pdf page-4.pdf pages-3-4.pdf

%d becomes the page number. Neither tool brought over the metadata or bookmarks in my test.

Password-protected files

Most bank statements open with a password, and splitting needs that password because the page tree is encrypted. qpdf without it:

$ qpdf --empty --pages locked.pdf 3-4 -- out.pdf
qpdf: locked.pdf: invalid password

With it, you put --password= after the file name inside the page list:

qpdf --empty --pages locked.pdf --password=YOURPASSWORD 3-4 -- out.pdf

The result came out unencrypted (pdfinfo says Encrypted: no), which is usually what the person asking expects, but it means the extract no longer needs a password, so send it the way you'd send any unprotected document. pdfseparate failed on the locked file with "Incorrect password", and the version I have (poppler 25.03.0) has no password option at all, so remove the password first if you're using poppler. Typing a password on the command line also leaves it in your shell history. qpdf has --password-file=, but it isn't accepted inside the --pages list (I got "unrecognized argument"), so to keep the password out of history, decrypt first and split the decrypted copy:

qpdf --decrypt --password-file=pw.txt locked.pdf unlocked.pdf
qpdf --empty --pages unlocked.pdf 3-4 -- pages-3-4.pdf

Then delete pw.txt and unlocked.pdf.

A browser option

I built ToolOcean, and its split page does the --empty kind of extraction in the browser without uploading the file. I ran the dummy statement through the live page in headless Chrome with the range 3-4: it saved split_pages_3-4.pdf with 2 pages, no Title, Author or Subject, and no bookmarks. The only network request after I picked the file was a 326-byte analytics ping, nowhere near the size of the PDF. Two differences from qpdf: it sorts pages into ascending order, so 5,2 gives page 2 first, and it can't open a password-protected file (it showed "Could not read the PDF file" for my locked copy), so remove the password first: toolocean.co/pdf-split.

Drafted with AI help, tested and checked by me.

Shooting a signature on a phone so it doesn't come out grey

Anuj Kabra — Sun, 01 Nov 2026 04:29:58 +0000

Upload forms that want a scanned signature usually mean "dark ink on a white background", within a pixel size and a KB range. A phone photo of a signature on white paper rarely looks like that. The paper comes out grey, often darker in one corner, and the file is bigger than it should be. Here's what I worked out about why, and how to fix it at the shooting step and afterwards, tested on dummy signature photos I generated (no real signatures).

Why white paper comes out grey

A phone camera sets its exposure so the scene averages out to a middle brightness. A sheet of white paper with a thin line of ink on it is almost all bright, so the camera turns the brightness down until the paper sits somewhere in the middle. Dim indoor light makes it worse: the paper gets darker, the camera raises its gain, and the grey picks up grain.

To see what that does to the file, I made two fake 4032 x 3024 phone photos of the same scribbled signature with Pillow and NumPy:

indoor.jpg    dim light: paper 48% to 63% grey, noisy, darker bottom right   2,261,328 bytes
daylight.jpg  window light: paper 87% to 92%, little noise                    1,273,147 bytes

The percentages are the average brightness of 50 x 50 pixel patches of paper, measured like this:

$ magick indoor.jpg -colorspace Gray -crop 50x50+3950+2950 -format '%[fx:round(100*mean)]%%' info:
48%

Same signature, same pixel count, and the indoor photo is 78% bigger. The ink didn't change. The noise did.

Shooting it so there's less to fix

Light: daylight near a window, not direct sun on the page. Turn the flash off; it leaves a bright spot in the middle and darker edges.
Exposure: after tapping to focus on the signature, drag the exposure control up a little (the sun icon next to the focus box on iPhone, a slider on most Android cameras) until the paper looks white on screen, but not so far that thin strokes start to fade.
Angle: hold the phone flat above the page, pointing straight down. A tilted shot turns a rectangle into a trapezoid and puts one side of the paper in more shadow than the other.
Your own shadow: with the light in front of you, the phone and your hand shade the page. Turn so the window is to one side.
Pen and paper: plain white paper with nothing showing through from the back, and a pen that gives a solid dark line. Ruled or textured paper adds lines and grain the file has to store.
Framing: fill a good part of the frame with the signature and leave some margin. You'll crop it anyway, and a signature that's 500 pixels wide in the photo holds up better than one that's 150.

Crop tight first

The rest of the photo is paper, and nobody asked for it. I cropped both photos to the same box around the signature (1569 x 559 pixels, starting at 1271, 1245) with a small margin. ImageMagick can find the ink for you if you threshold a copy first; %@ prints the bounding box of everything that isn't background:

$ magick indoor.jpg -colorspace Gray -threshold 30% -format '%@' info:
1489x479+1311+1285

That's width x height + left + top. I added 40 pixels on each side for the crop:

$ magick indoor.jpg -crop 1569x559+1271+1245 +repage -colorspace Gray -quality 85 crop.jpg

+repage drops the old canvas offset, so later steps treat the crop as a fresh image. -colorspace Gray keeps one channel instead of three, which suits a black or blue signature; skip it if the form insists the ink colour must show.

One thing that surprised me: at the same output width, cropping made the file bigger, not smaller.

600 px wide, quality 85
uncropped photo        600 x 450    10,851 bytes
cropped                600 x 214    16,456 bytes

In the uncropped version the signature is only about 220 pixels wide and most of the image is blurred, smoothed-out paper. Cropping is about making the signature fill the pixels the form gives you. It's the next step that brings the size down.

Make the paper white: -level, not just brightness

Raising brightness lifts the ink along with the paper, so you get pale grey on pale grey. What you want is to set a black point and a white point: everything darker than one value becomes black, everything lighter than another becomes white, and the strokes' soft edges are stretched in between.

$ magick indoor.jpg -crop 1569x559+1271+1245 +repage -colorspace Gray -level 25%,45% -quality 85 clean.jpg

My ink measured between 12% and 17% brightness and 99% of the pixels in the photo were above 46%, so 25% and 45% sit between the two. Check your own numbers with the fx:mean command above on a patch of paper near the darkest corner, and pick a white point a bit below it.

Here is what that does to the size. Same crop, same quality 85, the only difference is whether the paper is grey or white:

                          grey paper    white paper (-level)
full crop, 1569 x 559      109,093         36,100
resized to 600 px wide      15,040          9,940

At full size the white version is 67% smaller. JPEG stores each 8 x 8 block of pixels as a sum of patterns, and a block of flat white needs almost nothing. A block of grey paper with grain needs many patterns to describe the grain, so JPEG spends bytes on noise nobody wants. After -level, 93% of the pixels in the 600 px version were within 5 of pure white (250 or more); before it, none were.

The daylight photo shows that shooting well does most of the work:

600 px wide, quality 85, cropped, grey
indoor              15,040 bytes   (paper median 139 of 255)
daylight            10,054 bytes   (paper median 228)
daylight + -level    9,584 bytes

Threshold works, but it's rougher

-threshold makes every pixel pure black or pure white. It's tempting for a signature, and it's small, but the order matters:

-threshold 35% then -resize 600x    10,360 bytes   edges softened by the resize
-resize 600x then -threshold 35%    11,448 bytes   hard stair-step edges on curves
-level 25%,45% then -resize 600x     9,940 bytes   smooth edges

Thresholding after resizing gave the jaggiest result and was the biggest of the three, because hard edges are expensive for JPEG too. -level kept the smooth edges and came out smallest, so that's what I'd use.

One line, with automatic cropping

-trim removes borders that match the corner colour, and -fuzz sets how close counts as a match. On a grey, uneven photo it's useless on its own:

$ magick indoor.jpg -colorspace Gray -fuzz 10% -trim +repage -quality 85 out.jpg
1894 x 2943, 643,324 bytes

It kept most of the photo, because the paper gets darker towards one corner and that gradient doesn't match the corner colour. After -level the paper is flat white and -trim works, as long as the white point is low enough to clear the darkest paper:

$ magick indoor.jpg -colorspace Gray -level 25%,40% -fuzz 10% -trim +repage \
    -bordercolor white -border 40 -resize 600x -quality 85 signature.jpg
600 x 213, 10,002 bytes

With -level 25%,45% instead, a few noisy pixels in the dim corner stayed just below white, and -trim kept a 2723 x 1669 box to include them. At 40% it found the 1491 x 479 signature. If -trim returns something much bigger than the ink, lower the white point a little.

-border 40 puts a white margin back so the strokes don't touch the edge. If the form sets an exact size like 140 x 60 pixels, use -resize 140x60 -background white -gravity center -extent 140x60 so it fits inside and pads the rest with white rather than stretching. Some forms set a minimum KB as well as a maximum, and a clean signature can come out under it: that 140 x 60 version of my test signature was 1,551 bytes. Raising -quality, or the pixel size if the form allows a range, is the way back up.

Without the command line

Windows Photos: Edit image, then the crop tool to trim to the signature. The Adjustment panel has brightness, exposure, contrast, highlights and shadows; pushing exposure or highlights up until the paper turns white does roughly what -level does.
macOS Preview: draw a rectangle round the signature and use Tools > Crop. Tools > Adjust Color shows a histogram with sliders under it; dragging the right one left sets the white point and the left one right sets the black point, which is the same idea as -level. Saturation at zero makes it grey. Then File > Export as JPEG and watch the size as you move the quality slider.
Phone editors: most gallery apps can crop, and many have exposure, contrast and a black point slider in their adjust menu. Some also have a white point or highlights slider. A mono filter does the grey step.

I tested everything above on a Linux box with ImageMagick 7.1.2, so I haven't run these apps myself. The order is what carries over: shoot in good light, crop to the signature with a margin, set the paper to white, then resize and set the quality, and zoom in to check the thin strokes before uploading.

A browser option

I built ToolOcean, and its image-crop page does the crop step in the browser without uploading the photo. You drag a box on the image or type X, Y, width and height. I ran my indoor photo through the live page in headless Chrome with the same box as above: it saved cropped.png, 1569 x 559, pixel for pixel the same as ImageMagick's crop. As a PNG of grey, noisy paper that came to 1,278,084 bytes; the same crop of a copy I'd already put through -level was 155,733 bytes. So set the paper to white first (ToolOcean's image-filters page has brightness and contrast if you'd rather stay in the browser), and convert the result to JPEG at the end if the form wants one: toolocean.co/image-crop.

Drafted with AI help, tested and checked by me.

100 KB for a photo of a document: keeping the small print readable

Anuj Kabra — Sat, 31 Oct 2026 04:31:52 +0000

Upload forms often want a scan or photo of a document "under 100 KB". A phone photo of a page is often a few megabytes, and the obvious fix, dragging a quality slider down until the number fits, tends to turn the small print into mush. The order you do things in matters more than the slider. Here's what I worked out, tested on dummy document photos I generated (no real documents).

100 KB is two different numbers

Some software counts 1 KB as 1,000 bytes and some as 1,024, so "100 KB" is either 100,000 or 102,400 bytes. A form rarely says which. If you aim for 100,000 bytes or less, the file passes under either reading, so that's the target I use below.

My test photos

I drew an A4 page with Pillow at 300 pixels per inch (2480 x 3508): a title, 30 lines of body text at about 11 pt, and 14 lines of "small print" at about 8 pt full of 12-digit reference numbers. That last block is the part that has to survive. Then I made it look like a phone photo: tilted 3 degrees, on a brown desk, 3024 x 4032 pixels, a little sensor noise and blur, saved at JPEG quality 92. Four versions:

shadowed.jpg      uneven light + paper grain   2,090,034 bytes
shadow-only.jpg   uneven light, smooth paper   1,610,917 bytes
texture-only.jpg  even light + paper grain     2,293,309 bytes
even.jpg          even light, smooth paper     1,745,211 bytes

The "shadow" is a smooth darkening towards the bottom right, down to about half brightness in the corner. The "grain" is low-level blurred noise across the paper.

Quality alone doesn't get there

At full size, even Pillow's lowest quality settings were too big:

3024 x 4032, quality 1 -> 118,201 bytes
3024 x 4032, quality 0 -> 118,201 bytes

Twelve million pixels cost bytes even when each one is stored badly. So the job is to remove pixels you don't need first, and only then spend what's left on quality.

Step 1: crop to the paper and straighten

The desk is pure waste, and a tilted page means the crop has to include desk corners. I straightened first, then cropped. ImageMagick can measure the tilt for you:

$ magick shadowed.jpg -deskew 40% -format '%[deskew:angle]' info:
3.0047113682709132

It found the 3 degrees I'd put in. Then rotate the other way and crop to the page. In Pillow, rotate() with a positive angle turns anticlockwise, so my page needed -3, and the crop box came from looking at pixel positions in an image viewer: 282,272,2742,3760, which gives a 2460 x 3488 page.

Cropped and straightened but still full size, it fits, at quality 2 in colour (97,435 bytes) or 3 in grey (89,455 bytes). That fits the number and nothing else.

Step 2: pick the width, then search for quality

This is the step that decides whether the small print survives. I wrote a script that does all the steps and then binary-searches the JPEG quality for the largest file under the target. Quality and file size go up together, so halving the range each time finds the answer in about 7 encodes instead of trying all 95:

# fit.py: python fit.py in.jpg out.jpg [--angle A] [--box l,t,r,b] [--width W] [--gray] [--flatten] [--target BYTES]
# Straighten, crop, resize, optionally grey and flatten the lighting,
# then binary-search the JPEG quality for the largest file that fits.
import argparse, io
from PIL import Image, ImageFilter, ImageMath

ap = argparse.ArgumentParser()
ap.add_argument("src"); ap.add_argument("out")
ap.add_argument("--angle", type=float, default=0)       # degrees, positive = anticlockwise
ap.add_argument("--box")                                # crop after rotating
ap.add_argument("--width", type=int)
ap.add_argument("--gray", action="store_true")
ap.add_argument("--flatten", action="store_true")
ap.add_argument("--target", type=int, default=100_000)  # 100,000 fits both readings of "100 KB"
a = ap.parse_args()

im = Image.open(a.src)
if a.angle:
    im = im.rotate(a.angle, resample=Image.BICUBIC, expand=False, fillcolor="white")
if a.box:
    im = im.crop(tuple(int(v) for v in a.box.split(",")))
if a.width and a.width < im.width:
    im = im.resize((a.width, round(im.height * a.width / im.width)), Image.LANCZOS)
if a.gray:
    im = im.convert("L")
if a.flatten:
    # estimate the paper brightness around each pixel (local max, then blur),
    # divide it out, then push near-white paper to pure white
    g = im.convert("L")
    bg = g.filter(ImageFilter.MaxFilter(15)).filter(ImageFilter.GaussianBlur(25))
    g = ImageMath.lambda_eval(lambda e: e["g"] * 255 / e["bg"], g=g, bg=bg).convert("L")
    im = g.point(lambda v: 255 if v > 215 else int(v * 255 / 215))

def encode(q):
    buf = io.BytesIO()
    im.save(buf, "JPEG", quality=q, optimize=True)
    return buf.getvalue()

lo, hi, best = 1, 95, None
while lo <= hi:                       # about 7 encodes instead of 95
    q = (lo + hi) // 2
    data = encode(q)
    print(f"  q={q:2d} -> {len(data):,} bytes")
    if len(data) <= a.target:
        best, lo = (q, data), q + 1
    else:
        hi = q - 1
if best is None:
    print(f"{a.out}: even quality 1 is over {a.target:,} bytes at {im.size}; use fewer pixels")
else:
    open(a.out, "wb").write(best[1])
    print(f"{a.out}: {im.size[0]}x{im.size[1]} {im.mode}, quality {best[0]}, {len(best[1]):,} bytes")

Same page, grey, different widths, each searched down to 100,000 bytes:

width  quality  bytes
2460      3     89,455
1600      8     94,578
1240     13     95,756
1000     21     99,899
 800     34     97,692
 600     66     98,873

Fewer pixels means each one gets more bytes. The question is where the text stops being readable, and it depends on how tall the letters end up in pixels. My 8 pt line is 33 pixels per em at 300 DPI, so it's about 13 pixels at 1000 wide, 11 at 800 and 8 at 600. I zoomed in on the reference numbers in each file:

1240, 1000 and 800 px: every digit I checked read correctly. The low quality shows as block noise on the paper and smudges around the strokes, worst at 1240 with quality 13.
600 px, quality 66: far less block noise, but the digits are too small. 3, 5 and 8 start to look alike.

So for this page, 800 to 1000 pixels wide was where the digits stayed clear with the most quality to spare. A page with larger print can go narrower; a page with tiny print in a table may need 1240 and a cleaner photo. Check the smallest digits, not the headings.

Grey vs colour: less difference than I expected

To compare fairly I fixed the width (1240) and quality (30) and only changed the input:

shadowed, colour       194,462
shadowed, grey         187,898

Going grey saved only 3.4% here (2.2% at quality 60). That surprised me until I checked how the colour file was stored: Pillow uses 4:2:0 chroma subsampling by default, so the two colour channels are kept at a quarter of the resolution, and on a nearly grey page they're almost flat and cost very little. Grey still helps, and it helps more if the paper is tinted or has coloured stamps, but it's not the big lever. Pixels are.

What actually eats the bytes

Same width and quality again, the four photos side by side:

                      quality 30   quality 60
even, grey              160,301      227,318
texture-only, grey      225,555      352,794
shadow-only, grey       135,349      195,370
shadowed, grey          187,898      304,753

The paper grain added 41% at quality 30 and 55% at quality 60. JPEG stores each 8 x 8 block as a sum of patterns; a flat block needs almost nothing, and a grainy block needs many patterns to describe the grain, even though nobody wants the grain.

My smooth shadow didn't cost bytes on its own. It actually saved some, because darkening a region lowers the contrast of the text in it, and lower contrast is cheaper to store. That's not a good trade: it's the text getting fainter. In a real photo a shadow usually comes with more sensor noise as well, since the camera has less light to work with there, and noise costs bytes the same way grain does. My synthetic shadow had no extra noise, so this test doesn't show that part.

So the advice is the same either way: shoot in even light, near a window or under a ceiling light, and hold the phone so it doesn't throw its own shadow on the page.

If the photo is already shadowed, the --flatten option in the script divides out the lighting and pushes near-white paper to pure white. At 1240 px and quality 30 the shadowed page went from 187,898 to 169,992 bytes (9.5% smaller), and in the size-searched 1240 px file the background behind the small print came out white instead of grey and grainy.

ImageMagick in one line

The same steps with ImageMagick 7, using its own tilt detection and a size limit:

$ magick shadowed.jpg -deskew 40% +repage -gravity center -crop 2460x3488+0+0 +repage \
    -colorspace Gray -resize 1000x -define jpeg:extent=100000B out.jpg
$ magick identify -format "%wx%h %[colorspace] q=%Q %B bytes\n" out.jpg
1000x1418 Gray q=20 93808 bytes

Two things I ran into:

Without the +repage after -deskew, the crop used the old canvas offsets and cut off the left edge of the page.
jpeg:extent doesn't fail when it can't hit the target. Pointed at the full 3024 x 4032 photo it wrote a 118,310 byte file and exited with status 0. Always check the size afterwards.

It also stopped a step early: with the 100,000 byte limit above it settled on quality 20 (93,808 bytes), though -quality 21 on the same command gives 98,018 bytes and would have fit.

Without the command line

Windows Photos: the crop tool trims the desk, and the three-dot menu has Resize image, where you set a width in pixels, move the Quality slider, and see the new file size before saving.
macOS Preview: crop with the selection tool, Tools > Adjust Size for the width, Tools > Adjust Color with Saturation at zero for grey, then File > Export and use the JPEG quality slider, which shows the file size as you move it.
Phone editors: the crop tool in most gallery apps has a straighten dial, and a mono or black-and-white filter does the grey step. Crop and straighten there, then resize and set the quality on a computer.

I tested everything above on a Linux box, so I haven't run these apps myself. The order is the part that carries over: crop, straighten, choose a width where the smallest digits are still clear, then lower quality until it fits, and zoom in before uploading.

A browser option

I built ToolOcean, and its compress-image-to-100kb page does the last step: it picks the JPEG quality, and the scale if needed, so the file lands at or under the ceiling, in the browser without uploading the photo. Its 100 KB is 102,400 bytes. I ran two of my test files through the live page in headless Chrome. The raw shadowed photo came back at 1701 x 2268, 100,078 bytes; my cropped 1000 px grey page came back at 1000 x 1418, 101,075 bytes, saved as a colour JPEG. Both are under 102,400 and both are over 100,000, so a form that counts 1 KB as 1,000 bytes would reject them. The page doesn't crop, straighten or convert to grey, so do those first: toolocean.co/compress-image-to-100kb.

Drafted with AI help, tested and checked by me.

Turning phone photos of a marksheet into one small PDF

Anuj Kabra — Fri, 30 Oct 2026 04:28:19 +0000

A lot of upload forms want "one PDF, under 100 KB" for something you only have as phone photos: a two-sided marksheet, a certificate, a few pages of a transcript. Putting photos into a PDF is easy. Getting a small one with even pages takes knowing what the PDF actually does with your JPEGs. Here's what I worked out, tested on dummy marksheet-style images I generated (no real documents).

What a PDF does with a JPEG

A PDF can store a JPEG as-is. The image object gets the filter /DCTDecode (DCT is the maths inside JPEG), and the compressed bytes from your file are copied straight in. Nothing is decoded or recompressed, so quality doesn't drop. It also means the PDF can't be smaller than the photos inside it.

Other tools decode the JPEG to pixels and encode a new JPEG. That can make the file smaller or bigger depending on their quality setting, and it's a second round of lossy compression either way.

So the order matters: crop and compress the photos first, then put them in a PDF with something that copies JPEGs unchanged.

My test images

I made three "phone photos" with Pillow: a fake marksheet table on paper-coloured background, a brown desk border around it, some noise so it compresses like a photo, saved at quality 92. Two are 3024 x 4032, and a third is 2448 x 3264 as if taken on a different phone:

page1.jpg  3024x4032  1,441,946 bytes
page2.jpg  3024x4032  1,440,963 bytes
page3.jpg  2448x3264    974,380 bytes   (3,857,289 total)

img2pdf: JPEG passthrough

img2pdf (pip install img2pdf) embeds JPEGs without touching them:

$ img2pdf page1.jpg page2.jpg page3.jpg -o straight.pdf
$ ls -l straight.pdf
3859731 straight.pdf

That's 2,442 bytes more than the three photos together, which is the PDF structure. pdfimages -list (from poppler-utils) shows what's inside:

$ pdfimages -list straight.pdf
page   num  type   width height color comp bpc  enc interp  object ID x-ppi y-ppi size ratio
--------------------------------------------------------------------------------------------
   1     0 image    3024  4032  rgb     3   8  jpeg   no        13  0    96    96 1408K 3.9%
   2     1 image    3024  4032  rgb     3   8  jpeg   no         2  0    96    96 1407K 3.9%
   3     2 image    2448  3264  rgb     3   8  jpeg   no         5  0    96    96  952K 4.1%

To prove it's a straight copy, I pulled the images back out and compared bytes:

$ pdfimages -j straight.pdf x/s
$ cmp x/s-000.jpg page1.jpg && echo identical
identical

ImageMagick and Pillow re-encode

The same three photos through ImageMagick 7:

$ magick page1.jpg page2.jpg page3.jpg magick.pdf
$ ls -l magick.pdf
3493823 magick.pdf
$ pdfimages -j magick.pdf x/m
$ cmp x/m-000.jpg page1.jpg
x/m-000.jpg page1.jpg differ: byte 181, line 6

The image is still /DCTDecode, but it's a new JPEG: 1,301,295 bytes where the original was 1,441,946. ImageMagick decoded the photo and encoded it again.

Pillow does the same. This script:

# pillow_pdf.py: python pillow_pdf.py out.pdf a.jpg b.jpg ...
import sys
from PIL import Image
out, files = sys.argv[1], sys.argv[2:]
ims = [Image.open(f) for f in files]
ims[0].save(out, save_all=True, append_images=ims[1:], resolution=150)

gave a 1,584,553 byte PDF, with page 1's image re-encoded down to 588,020 bytes. Smaller, but that's quality loss you didn't choose, and still nowhere near 100 KB.

Step 1: crop and shrink the photos

For a document photo, most of the bytes go on things nobody needs: the desk, 12 megapixels, and colour on a page that's black text. This script crops to the paper, resizes, optionally converts to greyscale, and saves a JPEG at a chosen quality:

# shrink.py: python shrink.py in.jpg out.jpg left top right bottom [width] [quality] [gray]
import sys
from PIL import Image

src, out = sys.argv[1], sys.argv[2]
box = tuple(int(v) for v in sys.argv[3:7])
width = int(sys.argv[7]) if len(sys.argv) > 7 else 1240
quality = int(sys.argv[8]) if len(sys.argv) > 8 else 60
gray = len(sys.argv) > 9 and sys.argv[9] == "gray"

im = Image.open(src).crop(box)                 # cut the desk away
h = round(im.height * width / im.width)
im = im.resize((width, h), Image.LANCZOS)      # 1240 px is A4 width at 150 DPI
if gray:
    im = im.convert("L")                       # one channel instead of three
im.save(out, quality=quality, optimize=True, dpi=(150, 150))
print(out, im.size, im.mode)

The crop box comes from looking at the photo (any image viewer shows pixel positions). What each setting gave me, for all three pages through img2pdf:

1240 px wide, quality 60, colour  -> 150,709 bytes
1240 px wide, quality 60, grey    -> 131,641 bytes
1000 px wide, quality 40, grey    ->  87,696 bytes

Only the last one is under 100 KB. At 1000 pixels across an A4 width the marks and table lines were still clear when I zoomed in. My images are synthetic, so a real photo will land on different numbers; the method is to step width and quality down until it fits, then zoom in and check every digit is readable.

The gotcha: pages take the image's size, not A4

Look at the page sizes in straight.pdf. I checked them with pypdf:

# pages.py: print each page's size in pt and mm
import sys
from pypdf import PdfReader
for f in sys.argv[1:]:
    for i, p in enumerate(PdfReader(f).pages, 1):
        w, h = float(p.mediabox.width), float(p.mediabox.height)
        print(f"{f} page {i}: {w:.1f} x {h:.1f} pt = {w/72*25.4:.0f} x {h/72*25.4:.0f} mm")

straight.pdf page 1: 2268.0 x 3024.0 pt = 800 x 1067 mm
straight.pdf page 2: 2268.0 x 3024.0 pt = 800 x 1067 mm
straight.pdf page 3: 1836.0 x 2448.0 pt = 648 x 864 mm

Each page is the image's pixel size divided by a DPI. My test photos had no DPI in the header (the JFIF density was only an aspect ratio), so img2pdf assumed 96 and made pages nearly a metre tall. ImageMagick assumed 72 and went bigger still (1067 x 1422 mm). And because the third photo came from a "different phone", its page is smaller than the others. Print that and it comes out uneven; on screen the pages jump in size as you scroll. Even after cropping, my pages were 279, 279 and 277 mm tall, because no two crops are exactly the same shape.

The fix is to give the PDF a fixed paper size and let the image fit inside it:

$ img2pdf --pagesize A4 --border 10mm final1.jpg final2.jpg final3.jpg -o marksheet.pdf
$ pdfinfo marksheet.pdf | grep -E "Pages|Page size|File size"
Pages:           3
Page size:       595.276 x 841.89 pts (A4)
File size:       87696 bytes

All three pages are A4, and cmp on the extracted images still says identical: setting the page size only changes where the image is drawn, not the image data.

No OCR

The result is pictures of text. pdffonts lists no fonts, and pdftotext gave me back three page-break characters and no text. If a portal needs searchable text, that's a separate OCR step; none of the routes above does it.

Without the command line

Windows: select the photos in File Explorer, right-click, Print, and pick "Microsoft Print to PDF" as the printer. The paper size you choose there becomes the page size.
macOS Preview: open all the photos in one window, drag the thumbnails into order, select them all, then File > Print and choose Save as PDF from the PDF menu.
Phone scanner apps: the scan feature in many notes and file apps finds the page edges, crops and straightens. Check the size of what they export, since some save large colour pages.

I didn't run these on my Linux test machine, so I can't say whether they keep the JPEG or re-encode it. Either way, compress first and check the result with pdfimages -list and pdfinfo.

A browser option

I built ToolOcean, and its images-to-PDF page works the img2pdf way. I fed the live page two of my test photos in headless Chrome: both JPEGs came out byte-identical inside the PDF, and the pages were sized from the pixels (1067 x 1422 mm and 864 x 1151 mm, so the mixed-size gotcha applies). It doesn't crop, compress or OCR, so do those first: toolocean.co/images-to-pdf.

Drafted with AI help, tested and checked by me.

3.5 x 4.5 cm is not a pixel size: converting cm and DPI for form photos

Anuj Kabra — Thu, 29 Oct 2026 04:29:06 +0000

A lot of application forms ask for a passport-style photo of "3.5 x 4.5 cm". An image file has no centimetres in it. It has a width and height in pixels, plus an optional number in the header that says how many of those pixels should go into one inch when it's printed. Here's how I turn a size in cm into pixels, how to do it with free tools, and the one setting that looks like it changes the size but doesn't.

The formula

There are 2.54 cm in an inch, and DPI (dots per inch, often meaning pixels per inch for images) says how many pixels make one inch. So:

pixels = cm / 2.54 * DPI

The same 3.5 x 4.5 cm gives very different pixel sizes depending on the DPI. I ran it in Python and rounded to whole pixels:

$ python px.py
 96 DPI: 132.28 x 170.08 -> 132 x 170 px
200 DPI: 275.59 x 354.33 -> 276 x 354 px
300 DPI: 413.39 x 531.50 -> 413 x 531 px

All three are "3.5 x 4.5 cm". The 300 DPI version has about ten times as many pixels as the 96 DPI one (219,303 against 22,440), which matters for both sharpness and file size.

So a size in cm on its own is incomplete. If the form also gives a pixel size, I use the pixel size. If it gives cm and a DPI, I use the formula. If it gives only cm, I look in the notice and the portal's help for a pixel or DPI figure before guessing.

Step 1: crop to the right shape first

3.5 : 4.5 is the same shape as 7 : 9, a ratio of about 0.778. A phone photo is usually 3 : 4 (0.75). If you resize a 3 : 4 photo straight to 413 x 531, the width gets stretched by about 3.7 percent, enough to make a face look wider. So crop to 7 : 9 first, then resize.

For my 3024 x 4032 test image, that meant keeping the full width and cutting the height to 3024 x 9 / 7 = 3888 pixels, taken from the middle. In a real photo you'd place the crop so the face sits where the form's guidelines want it, rather than cutting blindly from the middle.

Step 2: resize and set the DPI with Pillow

This is the script I tested. It crops to 7 : 9 from the centre, resizes to the pixel size for the DPI you give it, and writes that DPI into the JPEG header:

# resize.py: python resize.py input.jpg 300 photo.jpg
import sys
from PIL import Image

src, dpi, out = sys.argv[1], int(sys.argv[2]), sys.argv[3]
w_px = round(3.5 / 2.54 * dpi)
h_px = round(4.5 / 2.54 * dpi)

im = Image.open(src).convert("RGB")
W, H = im.size
if W * 9 > H * 7:          # too wide: trim the sides
    new_w = H * 7 // 9
    left = (W - new_w) // 2
    im = im.crop((left, 0, left + new_w, H))
else:                      # too tall: trim top and bottom
    new_h = W * 9 // 7
    top = (H - new_h) // 2
    im = im.crop((0, top, W, top + new_h))

im = im.resize((w_px, h_px), Image.LANCZOS)
im.save(out, quality=85, dpi=(dpi, dpi))
print(out, im.size)

Output:

$ python resize.py phone.jpg 300 photo-300.jpg
photo-300.jpg (413, 531)

To check what I got, I read the pixel size and the JFIF density (the DPI field in the JPEG header) and worked out the printed size:

photo-96.jpg: 132x170 px, 1,414 bytes, JFIF density 96x96 dots/inch -> prints at 3.49 x 4.50 cm
photo-200.jpg: 276x354 px, 3,236 bytes, JFIF density 200x200 dots/inch -> prints at 3.51 x 4.50 cm
photo-300.jpg: 413x531 px, 5,713 bytes, JFIF density 300x300 dots/inch -> prints at 3.50 x 4.50 cm

The 3.49 and 3.51 come from rounding to whole pixels. My test image is a smooth synthetic picture, so the byte counts are much smaller than a real photo would be, but the direction is the same: more pixels, more bytes.

exiftool shows the same thing if you have it:

$ exiftool -ImageSize -XResolution -YResolution -ResolutionUnit photo-300.jpg
Image Size                      : 413x531
X Resolution                    : 300
Y Resolution                    : 300
Resolution Unit                 : inches

Doing it without code

Preview on a Mac: crop with the selection tool, then Tools > Adjust Size. The width and height fields have a unit menu, and there's a Resolution field. Apple's guide says that deselecting "Resample image" makes the dimensions smaller "without losing any detail". In practice that keeps the same pixels and changes only the print size and resolution. For a form photo that needs fewer pixels, keep "Resample image" ticked.
GIMP: Image > Scale Image changes the pixels (you can type the size in cm and set the resolution there). Image > Print Size only changes the resolution and print size. GIMP's own docs say Print Size "does not change the number of pixels in the image and it does not resample the image".
Paint on Windows: its Resize dialog works in percent or pixels, so do the cm to pixel maths yourself with the formula above, untick "Maintain aspect ratio" only after you've cropped to the right shape, and type the pixel size.

The gotcha: changing only the DPI does nothing to the pixels or the KB

It's tempting to open the file, change 96 to 300 in a DPI box, and call it done. I tried exactly that on the 96 DPI file by rewriting only the density bytes in the header:

photo-96.jpg: 132x170 px, 1,414 bytes, JFIF density 96x96 dots/inch -> prints at 3.49 x 4.50 cm
photo-96-relabelled-300.jpg: 132x170 px, 1,414 bytes, JFIF density 300x300 dots/inch -> prints at 1.12 x 1.44 cm

cmp -l found 4 bytes different between the two files, all in the header. Same pixels, same file size, and the printed size dropped to 1.12 x 1.44 cm because the same 132 pixels are now spread at 300 per inch. Doing the same relabel with exiftool -XResolution=300 -YResolution=300 -ResolutionUnit=inches gave the same 132 x 170 pixels; the file grew by 88 bytes only because exiftool also added an EXIF block holding the resolution.

So if a portal checks pixel dimensions or a KB range, editing the DPI field changes neither. What actually changes them is resampling to a new pixel size, and then compressing if the KB is still too high.

A browser option

I built ToolOcean, and its resizer page takes the size in px, cm, mm or inches with a DPI (96 by default, with 200 and 300 presets), does the conversion in the browser without uploading the photo, and stores that DPI in the JFIF header of a JPEG download. A PNG download keeps pixels only. It doesn't crop, so crop to the right shape first: toolocean.co/image-resizer.

Drafted with AI help, tested and checked by me.

Three months of statements as one PDF for a loan application

Anuj Kabra — Wed, 28 Oct 2026 04:28:07 +0000

Loan and rental forms often ask for the last three months of bank statements as a single upload. Banks usually hand them out one month at a time, and often with a password on each file. Here's how I join them into one PDF with free tools, and the three things that trip the job up: passwords, order, and size.

Step 1: find out which files are locked

A statement PDF can be protected in two ways:

An open password (user password). The file won't show its pages until you type it. Bank statements often come like this.
Owner restrictions only. The file opens without a prompt, but printing or copying is switched off. It's still encrypted.

pdfinfo from poppler-utils shows both. For my test files, the first has an open password and the second has owner restrictions only:

$ pdfinfo jul-locked.pdf
Command Line Error: Incorrect password

$ pdfinfo aug-restricted.pdf | grep Encrypted
Encrypted:       yes (print:no copy:no change:no addNotes:no algorithm:AES-256)

qpdf --show-encryption file.pdf gives more detail if you want it.

Step 2: why the merge fails on locked files

I tried merging all three files as they were. pdfunite, the merge tool that ships with poppler, refused both encrypted files, including the one that opens without a prompt:

$ pdfunite jul-locked.pdf aug-restricted.pdf sep.pdf out.pdf
Command Line Error: Incorrect password
Syntax Error: Could not merge damaged documents ('jul-locked.pdf')

$ pdfunite aug-restricted.pdf sep.pdf out.pdf
Unimplemented Feature: Could not merge encrypted files ('aug-restricted.pdf')

That second one is the gotcha. A file that opens fine on screen can still be rejected by a merge tool, because it's encrypted even though it has no open password.

Not every tool behaves the same. qpdf and pypdf both merged the owner-restricted file without complaint, and both stopped at the file with the open password (qpdf: jul-locked.pdf: invalid password, and pypdf raised FileNotDecryptedError). One note on pypdf: it needs the cryptography package installed to read AES-encrypted files, otherwise it fails with "cryptography>=3.1 is required for AES algorithm".

So the simplest rule is: remove the protection from each file first, then merge.

Step 3: remove each password (you need to know it)

With qpdf, for a file with an open password:

qpdf --decrypt --password=YOUR_PASSWORD jul-locked.pdf statement-2026-07.pdf

For an owner-restricted file, no password is needed:

qpdf --decrypt aug-restricted.pdf statement-2026-08.pdf

A wrong password gives invalid password and exit code 2, and no output file. After both commands, pdfinfo showed Encrypted: no on the new copies.

Typing the password on the command line leaves it in your shell history. qpdf can read it from a file instead with --password-file=pw.txt, which worked the same way in my test. Delete that file afterwards.

This only works for passwords you already have. It's a decrypt step, not a way to get into a file you can't open.

Step 4: put them in order, oldest to newest

Whoever reviews the application reads the file top to bottom, so I put the oldest month first. The easy way to get that order for free is to name the files by year and month, statement-2026-07.pdf, statement-2026-08.pdf, statement-2026-09.pdf, because the shell sorts the wildcard alphabetically:

pdfunite statement-2026-*.pdf statements-jul-sep-2026.pdf

The last name on the line is the output. Note that pdfunite overwrites it if it already exists.

To check the order, I printed the first line of each page:

$ for p in 1 2 3 4 5 6; do pdftotext -f $p -l $p statements-jul-sep-2026.pdf - | head -1; done
SAMPLE BANK - Account statement - July 2026 - page 1
SAMPLE BANK - Account statement - July 2026 - page 2
SAMPLE BANK - Account statement - August 2026 - page 1
SAMPLE BANK - Account statement - August 2026 - page 2
SAMPLE BANK - Account statement - September 2026 - page 1
SAMPLE BANK - Account statement - September 2026 - page 2

On scanned statements there's no text to extract, so open the merged file and flip through it instead.

qpdf can also do the decrypt and the merge in one command. A --password= written after a file name applies to that file:

qpdf --empty --pages jul-locked.pdf --password=YOUR_PASSWORD aug-restricted.pdf sep.pdf -- statements.pdf

That gave me a 6-page file with Encrypted: no.

On a Mac without the terminal: Apple's Preview guide describes combining PDFs by opening them, choosing View > Thumbnails, and dragging thumbnails (or a PDF's icon from the Finder) into another document's sidebar, then dragging thumbnails to reorder. Preview saves changes automatically, so Apple suggests File > Duplicate first if you want to keep the originals.

Step 5: check the size against the portal's limit

Merging copies pages; it doesn't compress them. The output is about the sum of the inputs. My text-only test statements were tiny, so I also made three scan-like statements with two image pages each:

File	Size (bytes)
scan-2026-07.pdf	2,412,623
scan-2026-08.pdf	2,412,521
scan-2026-09.pdf	2,412,750
Sum of inputs	7,237,894
Merged with pdfunite	7,236,678
Merged with qpdf	7,235,689

Three files of about 2.4 MB each became one file of about 7.2 MB. Upload limits differ from portal to portal, so check the portal's limit before you merge. If the merged file is over it, compress it as a separate step, and check that the figures are still readable afterwards.

A few more things I check before uploading

Page count. pdfinfo merged.pdf | grep Pages should equal the page counts of the inputs added together.
The merged file has no password. That's usually what a single-file upload needs. If you're emailing it instead, you can add a password to the merged copy with qpdf --encrypt.
Keep the originals. I work on copies and keep the bank's files untouched.

A browser option

I built ToolOcean, and it has a merge page that combines PDFs in the order you drag them into, in the browser without uploading the files. It doesn't take encrypted files, so a locked statement goes through its unlock page first, using a password you already know: toolocean.co/pdf-merge.

Drafted with AI help, tested and checked by me.

Filling a PDF form on a laptop, and why I flatten the copy I send

Anuj Kabra — Mon, 26 Oct 2026 04:19:39 +0000

A lot of forms still arrive as PDFs with a note that says "print, fill, scan, and send back". Most of the time you don't need the printer. Here's how to tell what kind of form you have, fill it with free tools, and decide whether the copy you send should still be editable.

Three things that look like a form

An AcroForm. The PDF stores a list of named fields (text boxes, checkboxes, radio groups, dropdowns), and each one has a widget on the page that draws its value. This is the kind almost every viewer can fill.
An XFA form. An older Adobe format where the form is described in XML inside the PDF. Most viewers outside Adobe's own apps can't render it.
A flat scan or export. Boxes and lines drawn on the page, with no fields at all. It only looks like a form.

pdfinfo (from poppler-utils) tells you which one you have on its Form: line:

$ pdfinfo form.pdf | grep Form
Form:            AcroForm

It prints AcroForm, XFA, or none.

The XFA gotcha

If you open a PDF and see only a page that starts with "Please wait... If this message is not eventually replaced by the proper contents of the document, your PDF viewer may not be able to display this type of document", that's an XFA form. Waiting won't help. Browsers and most free viewers show that placeholder page instead of the form. The realistic options are Adobe Acrobat Reader, which still fills XFA, or asking the sender for an AcroForm or Word version.

Filling an AcroForm without extra software

Chrome, Edge, Firefox and macOS Preview all fill AcroForm fields: open the file, click into a field, type, tick, and save. The saved file is still a form. Your answers sit in the fields, and anyone who opens it can change them.

If you get none, there's nothing to fill. You can still type on top using a viewer's text or annotation tool, but that's adding text to the page, not filling fields.

Filling from a script

For a form you fill often, a short pypdf script is handy. First list the field names, because they're whatever the form's author called them, not the labels you see:

import sys
from pypdf import PdfReader

for name, field in (PdfReader(sys.argv[1]).get_fields() or {}).items():
    print(name, field.get("/FT"), field.get("/_States_", ""))

On my test form:

full_name /Tx
agree /Btn ['/Off', '/Yes']

/Tx is a text field and /Btn is a checkbox or radio. The states in brackets are the exact values a checkbox accepts. Here it's /Yes, but some forms use /On or /1, so read them instead of guessing.

Then fill:

import sys
from pypdf import PdfReader, PdfWriter

src, out = sys.argv[1], sys.argv[2]
flatten = "--flatten" in sys.argv

reader = PdfReader(src)
writer = PdfWriter()
writer.append(reader)

values = {"full_name": "Test Person", "agree": "/Yes"}
for page in writer.pages:
    writer.update_page_form_field_values(page, values, auto_regenerate=False, flatten=flatten)

if flatten:
    writer.remove_annotations(subtypes="/Widget")
    del writer.root_object["/AcroForm"]

writer.write(out)

I tested this with pypdf 6.21. Without --flatten, the output is still a form with the values in the fields.

Why I flatten the copy I send

Flattening draws each field's appearance into the page content and removes the fields. The answers still show, but they're page content now, not a form someone can edit by accident (or on purpose) and send on.

With --flatten, my test file went from Form: AcroForm to Form: none, the field list came back empty, and pdftotext still printed "Test Person". Rendering the page with pdftoppm showed the name and the ticked box.

qpdf can flatten a file you already filled in a viewer:

qpdf --generate-appearances --flatten-annotations=all filled.pdf flat.pdf

--generate-appearances makes qpdf draw fields whose viewer didn't save an appearance, and --flatten-annotations=all burns them into the page. On my filled test file this gave the same result: Form: none and the values visible on the page. Note that all also flattens comments and other annotations, which is usually what you want for a final copy.

Two cautions. Keep an unflattened copy if you might need to change an answer, because flattening is one-way. And don't flatten a form the receiver asked for as a fillable file, since some offices read the field data straight out of it.

Signature fields

A signature field is a placeholder for a digital signature, not a text box. None of the methods above signs anything. If the form wants a drawn signature, add an image on the page; if it wants a real digital signature, that's a separate step with a certificate.

A browser option

I built ToolOcean, and it has a page that lists a PDF's AcroForm fields, lets you fill them, and downloads the result with flattening off by default. It runs in the browser without uploading the file, skips signature fields, and doesn't fill XFA forms: toolocean.co/pdf-form-fill.

Drafted with AI help, tested and checked by me.

My PDF was telling people who made it: checking and cleaning PDF metadata

Anuj Kabra — Sun, 25 Oct 2026 04:28:05 +0000

Before you send a PDF outside your team, it's worth knowing that the file carries a few labels you never typed on the page: an author name, a title, the app that made it, and when. Those labels often hold a draft title or your computer's account name. Here's how to see them and remove them with free tools, and why the most common one-liner doesn't fully remove anything.

Where the labels live

A PDF can describe itself in two places:

The Info dictionary. A small key/value table: Title, Author, Subject, Keywords, Creator (the app that made the document), Producer (the library that wrote the PDF), and the creation and modification dates.
The XMP packet. An XML block stored as a metadata stream. It usually repeats the same ideas (for example dc:creator for the author and xmp:CreatorTool for the app) and can hold more.

Cleaning only one of them leaves the other behind, so check both.

Reading them

I made a one-page test PDF with an author, a title and an XMP packet, then read it.

pdfinfo (from poppler-utils, on most Linux distros and in Homebrew) shows the Info dictionary:

$ pdfinfo sample.pdf
Title:           Draft offer letter v3
Subject:         Internal
Keywords:
Author:          Test Author
Creator:         Writer on my laptop
Producer:        ReportLab PDF Library - (opensource)
...
Metadata Stream: yes

That last line tells you an XMP packet exists. pdfinfo -meta sample.pdf prints it as raw XML.

exiftool reads both places and labels which one each value came from:

$ exiftool -a -G1 -s sample.pdf
[PDF]      Author        : Test Author
[PDF]      Creator       : Writer on my laptop
[PDF]      Title         : Draft offer letter v3
[XMP-dc]   Creator       : Test Author
[XMP-xmp]  CreatorTool   : Writer on my laptop

[PDF] is the Info dictionary and [XMP-...] is the XMP packet.

The one-liner that only hides things

The usual advice is:

exiftool -all:all= file.pdf

Afterwards, exiftool and pdfinfo both report no author. But exiftool prints a warning while it works:

Warning: [minor] ExifTool PDF edits are reversible. Deleted tags may be recovered!

It means what it says. For PDFs, exiftool appends an update to the end of the file instead of rewriting it, so the old Info dictionary is still in the bytes. On my test file, grep -c "Test Author" still found the name twice after the "strip", and this command brought every value back:

exiftool -pdf-update:all= file.pdf

So after exiftool, rewrite the file so the unreferenced old objects are dropped. qpdf does that:

exiftool -all:all= file.pdf
qpdf --linearize file.pdf clean.pdf

On clean.pdf, grep found no copy of the name, and exiftool showed no author.

Another route: copy only the pages

If you have Python, pypdf can build a new PDF from the pages alone, which leaves out the old Info dictionary and the XMP packet:

import sys
from pypdf import PdfReader, PdfWriter

r = PdfReader(sys.argv[1])
w = PdfWriter()
for page in r.pages:
    w.add_page(page)
w.write(sys.argv[2])

python strip.py in.pdf out.pdf gave a file where pdfinfo showed only Producer: pypdf and Metadata Stream: no. Bookmarks, form fields and other document-level parts don't come across this way, so check the output.

What none of this touches

Metadata is not page content. My test page said "Prepared by Test Author", and after every method above, pdftotext clean.pdf - still printed that line. A name in the text, in a header or footer, in a comment, or inside an attached file has to be removed in the source document or with a real redaction step. Also, don't use grep to check page text: page streams are usually compressed, so grep can miss text that is plainly visible on the page.

The cheapest fix is often upstream: clear the author and title in the document properties of the app you write in, then export again.

A browser option

I built ToolOcean, and it has a page that reads both the Info dictionary and the XMP packet in your browser, lets you edit or strip them, and saves a new copy without uploading the file. Its strip doesn't touch page content either, and it refuses encrypted files: toolocean.co/pdf-metadata.

Drafted with AI help, tested and checked by me.

Password-protecting a PDF before emailing it, and why the "no printing" box isn't a lock

Anuj Kabra — Sat, 24 Oct 2026 04:23:42 +0000

Bank statements, salary slips and ID scans get emailed around all the time. Putting a password on the PDF first is cheap insurance: if the mail lands in the wrong inbox or sits in a shared folder, the file is useless without the password. It only works if you know what the password actually protects, and PDF encryption has two passwords that do very different jobs.

Two passwords, two jobs

The open password (the spec calls it the user password). A reader won't show any page until you type it. This is the part that keeps a stranger out.

The owner password. It controls the permission flags: printing, copying text, editing, filling forms, and so on. Someone who opens the file with the open password gets the restricted version. Someone who opens it with the owner password gets everything.

The file is encrypted either way. The flags are different: they're a request written into the file, and it's up to the reader software to honour it. I'll show below what that means in practice.

Built-in ways to do it

You may not need anything new:

Microsoft Word (Windows): File > Save As, choose PDF, click Options, and tick "Encrypt the document with a password".
LibreOffice: File > Export as PDF, open the Security tab, and use Set Passwords. It asks for the open password and the permissions password separately.
macOS Preview: recent versions have File > Edit Permissions, where you can require a password to open the document and set an owner password for the permissions.

Whatever you use, open the result afterwards and confirm it asks for the password before you delete the original.

From the command line with qpdf

qpdf is free and open source, and it's my go-to when I want to know exactly what's in the file. This sets a different open and owner password, uses 256-bit AES, and turns off printing and copying:

qpdf --encrypt --user-password=river-cobalt-42 --owner-password=Owner-only-9x \
  --bits=256 --print=none --extract=n -- statement.pdf statement-protected.pdf

Then check what you made:

qpdf --password=river-cobalt-42 --show-encryption statement-protected.pdf

On my test file that printed R = 6, Supplied password is user password, print high resolution: not allowed, extract for any purpose: not allowed, and AESv3 for streams, strings and files. R = 6 with AESv3 is the AES-256 handler from PDF 2.0, the strongest standard option a PDF has.

poppler's pdfinfo makes a good second check, because it won't touch the file without the password:

pdfinfo statement-protected.pdf
# Command Line Error: Incorrect password
pdfinfo -upw river-cobalt-42 statement-protected.pdf | grep Encrypted
# Encrypted: yes (print:no copy:no change:yes addNotes:yes algorithm:AES-256)

Why the "no printing" box isn't a lock

Here's the part that surprised me. With that same file and only the open password, two ordinary commands ignored the restrictions completely.

pdftotext pulled the text out, even though the file says copying isn't allowed:

pdftotext -upw river-cobalt-42 statement-protected.pdf - | head -2
# Account statement, test file
# Balance: 12,345.67

And qpdf wrote a fully decrypted copy with no restrictions at all:

qpdf --password=river-cobalt-42 --decrypt statement-protected.pdf plain.pdf
qpdf --show-encryption plain.pdf
# File is not encrypted

That isn't a bug in either tool. Once you have the open password, you can decrypt the content, and the flags are only a note asking the reader to behave. Acrobat and most mainstream viewers respect them. A script doesn't have to. So treat the permission flags as a guard against accidental editing or printing by a cooperative reader, not as a way to stop a determined recipient from copying something you've already let them read.

If you want the flags to mean anything, the owner password has to be different from the open password. When I encrypted the same file with both passwords set to the same string, --show-encryption reported Supplied password is owner password for the open password, which means anyone who can open the file holds the full set of rights.

Sending the password

The point of the password is lost if it travels in the same email as the file. Send it by another channel: a text message, a call, or a password you agreed earlier. For recurring documents, some banks and employers use a pattern built from your name and date of birth, which is convenient and also guessable by anyone who knows you. For files you protect yourself, use a long passphrase. AES-256 isn't the weak point; a short password is, because an attacker with the file can try guesses offline as fast as their hardware allows.

Gotcha: a blank owner password can mean no password at all

Leaving the owner password empty feels harmless, as if it just means "no extra restrictions". With 256-bit encryption it's worse than that. qpdf refuses outright:

qpdf: A PDF with a non-empty user password and an empty owner password
encrypted with a 256-bit key is insecure as it can be opened without a password.

I forced it with --allow-insecure to see, and the warning is accurate. pdfinfo opened the result with no password at all and printed Encrypted: yes (print:yes copy:yes ...), and pdftotext read the text straight out. A reader tries the empty string as the owner password, it matches, and the open password never gets asked for. If a tool lets you leave the owner password blank, check what it writes in its place, then test the output with pdfinfo before you send it.

I built ToolOcean, a set of browser-based file tools. Its password page encrypts with AES-256 (revision 6) in the browser tab, and when the owner password is left blank it stores a copy of the open password instead of an empty one, so the file still needs a password to open: https://toolocean.co/pdf-encrypt

Drafted with AI help, tested and checked by me.