DEV Community: xiaomei Lu

Is that 'free file converter' uploading your file? A 60-second DevTools audit

xiaomei Lu — Mon, 22 Jun 2026 16:57:14 +0000

You drag a sensitive PDF — a contract, a passport scan, a payslip — onto some "100% free, secure, private" online converter. It spits out the result in two seconds. The page swears it "deletes your files after processing."

Here's the thing: you have no way to verify that claim. "We delete after processing" is a promise about a server you can't see, running code you can't read, with a retention policy you can't audit. It might be true. It might be true today and not next quarter.

But you don't have to trust the promise. If your file never left your browser, there's nothing to delete and nothing to subpoena. And whether or not it left is a fact you can check yourself in about 60 seconds.

Here's the skill.

The 60-second audit

Open the tool's page in Chrome/Edge/Firefox.
Open DevTools (F12 or Cmd+Opt+I), go to the Network tab.
Click the 🚫 clear button to start clean. Leave "Preserve log" off for now.
Run the conversion — pick your file, hit convert.
Watch what rows appear.

That's it. You're now looking at every request the page made. The question is simple: did one of them carry your file out?

A faster way to find the row: type your filename into the Network tab's filter box, or click Fetch/XHR to hide assets, then sort by the Size column. At convert-time, a row roughly the size of your file (a ~2 MB row for a 2 MB file) is the one to inspect.

What an upload looks like

When a tool sends your file to a server, you'll see a request that is unmistakable once you know the shape of it. Click the row and look at the Headers and Payload tabs. You'll see something like:

Request URL:    https://api.someconverter.com/v1/convert
Request Method: POST
Status Code:    200

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryAb3x
Content-Length: 2487193

Two tells:

Method is POST or PUT, not GET.
Content-Type: multipart/form-data with a Content-Length roughly the size of your file (here, ~2.4 MB — that's your file in bytes).

Open the Payload tab (in Firefox, click the request and open the Request tab) and you'll see the form-data parts:

------WebKitFormBoundaryAb3x
Content-Disposition: form-data; name="file"; filename="contract.pdf"
Content-Type: application/pdf

%PDF-1.7
%âãÏÓ
... (binary bytes of your actual file) ...

That filename="contract.pdf" followed by %PDF bytes is the smoking gun. Your file is, right now, sitting in a request body headed to someone else's machine. No amount of "we delete it" changes the fact that it left.

(Sometimes it's application/octet-stream or a base64 blob in a JSON body instead of multipart — same story. A big POST/PUT body sized like your file = upload.)

What a genuinely client-side tool looks like

Now run the same audit on a tool that processes locally. The signature is almost funny in how boring it is:

You pick your file. No new network row appears at the moment of conversion.
The result downloads — but as a blob: URL the page generated in memory, not a response from a server.

The only requests you'll ever see are the page's own assets (JS, CSS, fonts) on first load, and — for some tools — a one-time download of a model or WASM binary. That part trips people up, so let's be precise.

The one nuance: a fetch is not always your file

Some browser-native tools download a chunk of machinery the first time you use them. OCR pulls a WASM build of Tesseract plus a trained language model; in-browser background removal pulls an ML model file. In the Network tab that looks like:

Request URL:    .../tesseract-core.wasm
Request Method: GET
Status: 200    Size: 4.2 MB

Request URL:    .../eng.traineddata.gz
Request Method: GET
Status: 200    Size: 10.4 MB

This is not your file leaving. Three reasons you can tell them apart:

Method is GET — it's pulling code down, not pushing a file up.
It's the same file/model regardless of what you convert, and it's cached — convert a second file and it's served from disk cache (you'll see "(disk cache)" in the Size column), or there's no request at all.
The bytes flow to you. Your document is never in a request body.

So the honest rule: a GET for a .wasm or model file is fine. A POST/PUT carrying your filename and bytes is an upload. And yes — a WASM tool could still phone home (analytics, "anonymous" telemetry, error reporting with your filename in it). The audit catches that too: if there's any outbound POST with your data in it, you'll see it.

The honest part (disclosure)

I build bestaifinds.com — 240+ free, no-signup file tools — and this audit is exactly the principle I build on, so I'll hold myself to it.

Open the Network tab on the image and PDF-structure tools and you'll see no upload: image compress, remove background, image→text OCR, PNG→WebP, PDF merge, PDF split. Convert once, watch the panel, then convert again and watch it stay quiet. The model/WASM download is the only thing that crosses the wire.

And I'll be straight about the rest. A few tasks genuinely can't run in the browser yet:

Video (ffmpeg). ffmpeg.wasm exists, but transcoding a real clip in WASM is slow and memory-hungry enough that a real ffmpeg binary is just better.
Ghostscript-grade PDF compression and PDF→text — real downsampling and quality text extraction want native binaries.
HEIC decode — most browsers can't natively decode HEIC, so HEIC→JPG leans on libheif/ImageMagick.

So PDF compression, PDF→text, HEIC→JPG, and all the video tools do go to a server — and the file is deleted right after. That last claim you'll have to take on trust, which is the whole point of this post: when a heavy task claims to be 100% local, audit it, because sometimes "in your browser" quietly means "in our browser, on our server." Prefer the tools where you don't have to trust.

So next time something promises "private and secure," open the Network tab and let the wire tell you.

What conversion do you wish ran fully in your browser but always seems to need an upload? Drop it in the comments — genuinely useful for deciding what to build (or audit) next.

PDF, image & video chores: the CLI one-liner + a browser fallback for each

xiaomei Lu — Mon, 15 Jun 2026 12:08:37 +0000

You need to convert one file. Just one.

A teammate sends a .heic screenshot and your image viewer shrugs. The contact form needs a PDF under 5 MB and yours is 11. You recorded a 40 MB screen capture and the bug tracker only accepts GIFs. You don't want to brew install a tool you'll use once, and you really don't want to drop a half-confidential document into the first sketchy "free converter" Google surfaces.

So here's the cheat sheet I keep coming back to: for each common file chore, the CLI one-liner if you live in a terminal, and a no-install browser tool when you don't (or when you're on someone else's machine). I'll be honest about which is better for what — and at the end, which ones run on your own machine vs. on a server.

Disclosure: I build the browser tools I link to (bestaifinds.com). The CLI commands are the real recommendation; the web tools are the fallback for when you can't install anything.

PDFs

Get a PDF under an email/upload limit

gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook \
   -dNOPAUSE -dQUIET -dBATCH -sOutputFile=out.pdf in.pdf

Ghostscript's /ebook preset is the sweet spot — /screen for brutal compression, /printer to keep quality (the PDFSETTINGS docs list what each one does). No Ghostscript handy? → compress it in the browser.

Pull the text out of a PDF (to grep / parse / diff)

pdftotext in.pdf out.txt        # ships with poppler-utils

Indispensable for log-style PDFs and a quick grep. pdftotext (and pdfunite below) come from poppler.

Merge / split

pdfunite a.pdf b.pdf c.pdf merged.pdf       # poppler
qpdf --split-pages in.pdf page.pdf          # -> page-1.pdf, page-2.pdf, ...

qpdf inserts the page number before the extension automatically. No install? → merge in the browser.

Images

Shrink images / ship WebP

cwebp -q 80 photo.png -o photo.webp         # libwebp, lossy by default
cwebp -lossless ui.png -o ui.webp           # for screenshots / flat UI / line art

Over a photographic PNG, lossy WebP at q80 often saves 60–80%; over an already-compressed JPEG, expect more like 20–35% (sometimes less — you're re-encoding existing artifacts). Use -lossless (or -near_lossless) for screenshots and logos, where lossy q80 shows visible ringing. It clears Lighthouse's "next-gen formats" / "efficiently encode images" opportunities and trims LCP. cwebp options → No install? → compress images in the browser.

A note on magick input.jpg -quality 80 out.jpg: re-encoding an already-compressed JPEG to a fixed quality only helps if the original was saved higher than q80 — otherwise it adds a generation of loss and can make the file bigger. For an existing JPEG, reach for a lossless optimizer (jpegtran, jpegoptim) or convert to WebP instead.

Remove a background (avatars, OG images, READMEs)

rembg i input.png output.png    # pip install "rembg[cpu]" first; downloads a model on first run

rembg is great, but it's a Python dep + a model download for a 10-second job. For one image: → remove a background in the browser (the model runs client-side — more on that below).

OCR — image/screenshot → text

tesseract screenshot.png out    # writes out.txt

Tesseract is excellent if it's installed.

That iPhone `.heic` nobody can open

magick photo.heic photo.jpg          # ImageMagick built with libheif
heif-convert photo.heic photo.jpg    # ships with libheif (Debian: libheif-examples; Homebrew: libheif)

libheif does the actual HEIC decoding under both.

Video

MP4 → GIF (for a PR demo or a bug repro)

ffmpeg -i clip.mp4 -vf "fps=12,scale=480:-1:flags=lanczos" clip.gif

For crisp colors, generate a palette first — ffmpeg's high-quality GIF guide walks through palettegen/paletteuse; worth it for screen recordings. No ffmpeg? → MP4 to GIF in the browser.

Rip the audio: MP4 → MP3

ffmpeg -i talk.mp4 -q:a 0 -map a talk.mp3

The honest part: what runs where

"Free online converter" usually means your file gets uploaded to someone's box. That matters for anything remotely confidential. So here's the straight answer for the browser tools I linked above (I build them, so I checked the actual code path):

Runs entirely in your browser — the file itself is never uploaded:
image compress / resize / format-convert, PNG→WebP, OCR (Tesseract compiled to the browser), background removal (an in-browser ML model), and PDF merge / split / to-JPG / from-JPG (via pdf-lib and pdf.js, both running in your browser). Open DevTools → Network and you'll see the file is never POSTed — the only fetch is the background-removal model, downloaded once, then everything runs locally.

Runs server-side, then deletes after processing:
PDF compression (Ghostscript/qpdf), PDF→text, HEIC→JPG (ImageMagick), and all video work (ffmpeg) — these need real binaries no browser ships. For anything sensitive, prefer the CLI here.

That distinction is the whole reason I dislike most converter sites: they don't tell you. So now you know which is which.

TL;DR

Living in a terminal already? The CLI one-liners above cover almost all of these chores.
On a borrowed machine, or it's a one-off? The browser tools skip the install.
Care about privacy? Use the client-side tools or the CLI for anything you wouldn't email.

The browser tools are all free and signup-free at bestaifinds.com. I built the site partly because I was tired of choosing between installing yet another dependency and trusting a random upload box. If there's a file chore you do constantly that I missed, drop it in the comments — genuinely useful for deciding what to build next.

Getting images actually web-ready: compress, resize, and pick the right format without opening an editor

xiaomei Lu — Sun, 07 Jun 2026 16:23:18 +0000

A surprising amount of "my site is slow" comes down to one thing: someone dropped a 4032x3024 photo straight off their phone into a content block that renders at 800px wide. The browser downloads all 5 MB and then throws most of it away during resize. Multiply that by a dozen images and you've got a page that takes 8 seconds on a hotel wifi.

Getting an image "web-ready" is really three decisions made in order: resize first, then choose a format, then compress. Do them in that order and you usually cut file size by 80-95% with no visible quality loss. Here's how to actually do it, with the numbers that matter.

Step 1: Resize to the size it's displayed at (this is the big win)

This is the step people skip, and it's the one that matters most. Pixels you can't see still cost bytes.

Figure out the largest size the image is ever shown at, then add a buffer for high-DPI screens:

Full-width hero on a normal layout: cap at ~1920px wide. Even 4K monitors rarely render a content image wider than that.
Blog post inline image / content column: the column is usually 700-800px, so export at 1600px (2x for retina) and let CSS scale it down.
Thumbnail / avatar / card image: displayed at 200px? Export at 400px. No more.
Icons and logos: if it's flat/geometric, this should be an SVG, not a raster image at all.

The math is brutal in your favor here. A 4000x3000 image is 12 million pixels. Resized to 1600x1200 it's 1.9 million pixels — 84% gone before you've compressed anything. Resizing from 4000px to 1600px usually takes a 5 MB JPEG down to roughly 600-900 KB on its own.

Quick rule: if the longest edge of your file is bigger than 2000px and it's not a print asset or a zoomable gallery image, it's too big.

Step 2: Pick the right format

Format choice is mostly about what's in the image:

Photographs / complex gradients → JPEG or WebP. Lots of color, no hard edges, no transparency. JPEG is universally supported; WebP is ~25-35% smaller at the same quality and supported by every browser shipped in the last 5+ years.
Screenshots, UI, text, line art, anything with sharp edges → PNG or WebP (lossless). JPEG turns crisp edges into a smeary mess of artifacts. This is the #1 format mistake — saving a screenshot of code as a JPEG.
Needs transparency → PNG or WebP. JPEG has no alpha channel.
AVIF is the smallest of all (often 20% under WebP) but it's slower to encode and a bit fussier; great for hero images where the savings are worth it, overkill for thumbnails.

Honest default for 2026: WebP for almost everything, with a JPEG fallback only if you're targeting truly ancient clients. If you don't want to think about it, JPEG for photos and PNG for screenshots is still perfectly fine and will never surprise you.

Step 3: Compress with a target quality, not "maximum"

For lossy formats (JPEG/WebP/AVIF), quality is a 0-100 dial, and the sweet spot is lower than people expect:

Quality 80-85 is the standard "looks identical, much smaller" zone for photos. Start here.
Quality 70-75 is fine for thumbnails and background images where nobody's pixel-peeping.
Above 90 you're mostly adding bytes you can't see. Below 60 you start to notice blocking in skies and skin tones.

A typical 1600px photo at quality 82 lands around 120-200 KB. That's the target to aim for on a content image. If you're well above 300 KB after resizing, your quality setting is too high or the format is wrong for the content.

For PNG screenshots, "quality" works differently — you reduce the color palette (e.g. down to 256 colors) and run lossless optimization. A flat UI screenshot can drop 60-70% with palette reduction and look identical.

Doing it without installing anything

If you live in the terminal, the local CLI tools are excellent and worth knowing — they're scriptable, run offline, and keep files on your machine:

ImageMagick: magick input.jpg -resize 1600x -quality 82 output.jpg does resize + compress in one shot. mogrify batches a whole folder.
cwebp: cwebp -q 80 input.png -o output.webp for WebP conversion.
sharp (Node) or Pillow (Python) if you want this baked into a build step or an upload pipeline. This is the right answer for anything recurring.
squoosh-cli wraps the same encoders Squoosh uses, good for AVIF.

If it's a one-off, or you're on a machine where you can't install things, or you just don't want to remember ImageMagick's flag soup, a browser tool is faster. Web options worth knowing: Squoosh (Google's, the gold standard for fiddling with one image and watching the quality slider in real time, fully client-side), TinyPNG (dead simple, great auto-compression, but free tier caps file size and count), and Photopea if you also need to actually edit.

For the plain resize-then-compress run I described above, I usually point people at the image tools on BestAIFinds — full disclosure, I help build that one, so weigh that accordingly. There's a compress tool, a separate resize tool, and format conversion, all free with no sign-up or watermark, and uploads auto-delete within about an hour. Squoosh is genuinely better if you want to manually tune one image with a live preview, so use that when you care about a single hero shot. For batching a folder, honestly just use ImageMagick.

The privacy caveat you should actually think about

Any browser tool that uploads to a server means your image touches someone else's machine, even if it's deleted an hour later. For a marketing photo or a screenshot of public docs, who cares. For anything with PII, internal dashboards, unreleased product shots, medical or legal material — use a local CLI or a fully client-side tool (Squoosh and ImageMagick never send your file anywhere). This isn't paranoia, it's just matching the tool to the sensitivity of the file. Read whether a tool processes in-browser or server-side before you paste in something confidential.

Putting it together

The whole workflow for a typical content image:

Resize longest edge to ~1600px (or 2x your display size). Biggest single saving.
Pick format: WebP or JPEG for photos, PNG/WebP for screenshots and UI.
Compress to quality ~82 for photos, ~75 for thumbnails. Aim for under ~200 KB.
Sanity-check the output actually looks fine at the size it'll be shown, not zoomed to 400%.

Do those four things and a page that was shipping 6 MB of images ships maybe 600 KB, with no visible difference. Your Lighthouse score, your mobile users, and your bandwidth bill all thank you.

What's your default quality setting and format these days — has WebP fully replaced JPEG in your workflow, or are you still shipping JPEG fallbacks? Curious what edge cases are keeping people on the old formats. Drop a comment.

Free browser tools for the boring file tasks every dev runs into

xiaomei Lu — Tue, 02 Jun 2026 07:02:55 +0000

Every few days I hit some small file chore that has nothing to do with the actual work: a PDF too big to email, a screenshot that needs a transparent background, a CSV someone wants as JSON. None of it is hard. It's just annoying enough to break my flow, and the first Google result is usually a desktop app that wants an install and an account before it'll do a 5-second job.

Over time I've collected a set of browser-based tools that handle this stuff without any of that friction. Here's the practical roundup, with concrete steps for the tasks that come up most.

Compress a PDF before emailing it

Mail servers commonly reject attachments over ~10-25 MB, and exported PDFs (especially anything with images or scans) blow past that fast.

The steps are basically the same everywhere:

Open a PDF compressor in your browser.
Drag the file in.
Pick a compression level — "medium" is usually the sweet spot between size and readable text.
Download and check it still looks fine before you send.

The thing to watch: heavy compression can soften scanned text or photos. Always eyeball the output. If it's a contract or anything someone has to read carefully, stay on the lighter setting.

Tools I've used for this: Smallpdf, PDF24, and BestAIFinds (full disclosure, I help run that last one). All three do the same core job in the browser. PDF24 is nice because it's genuinely no-account; Smallpdf has a free tier with daily limits. The one I help with is free with no sign-up and no watermark, and it auto-deletes uploads within about an hour — but honestly, for a one-off, grab whatever tab is already open.

Remove an image background

This used to mean opening an editor and masking by hand. Now an automatic remover gets you 90% of the way in one click — great for product shots, profile pictures, or dropping a logo onto a slide.

How it goes:

Upload the image (PNG/JPG).
Let it auto-detect the subject.
Download as a transparent PNG.

It struggles with fine detail — wispy hair, glass, motion blur. For those, Photopea is worth knowing about: it's a free, in-browser Photoshop clone where you can clean up edges manually with the same keyboard muscle memory. For the quick automatic version I'll use an in-browser remover like the one on BestAIFinds, but the workflow is identical across tools.

Convert formats without a round-trip

The two that come up constantly:

PDF to Word when you need to edit text in a doc someone "helpfully" sent as a PDF. Formatting is the hard part — tables and columns are where converters fall apart. Run it, then spend two minutes fixing layout rather than expecting it to be perfect.
CSV / Excel / JSON / XML when you're moving data between a spreadsheet and something that speaks JSON. For small files a browser converter is faster than writing a one-off script; for anything large or repeatable, just use pandas or jq and move on.

iLovePDF and Smallpdf both cover the PDF conversions well. I'll often reach for whatever's already open in a tab.

A few honest caveats

Browser tools are great, but know their limits:

Privacy: anything you upload leaves your machine. Don't put confidential contracts, customer data, or anything under NDA through a random web tool. Check the deletion policy first — some auto-delete uploads within an hour, some are vaguer about it. For sensitive files, prefer a local CLI (qpdf, ghostscript, ImageMagick, ffmpeg) that never sends bytes anywhere.
Scriptability: if a task repeats, automate it. A web UI is for one-offs; for the tenth time, write the script.
Free tiers: "free" sometimes means a couple of files a day or a watermark. Read before you rely on it for a deadline.

A quick reference list

Tasks → what I tend to grab:

PDF too big to email → any browser compressor, "medium" level, eyeball the result
PDF → editable text → a PDF-to-Word converter, then fix tables by hand
Transparent background → automatic remover for speed, Photopea for fiddly edges
Spreadsheet ↔ JSON → browser converter for small one-offs, pandas/jq for real pipelines
Compress/convert video → an in-browser video tool for short clips, ffmpeg for batches

Sign-off

There's no magic here — these are all variations on "upload, click, download." The point is just to not lose 20 minutes installing software for a job that takes seconds. Keep a couple of these bookmarked, keep a local CLI around for anything private or repeatable, and you'll rarely get stuck.

If you've got a go-to tool I didn't mention, drop it in the comments — I'm always swapping mine out.