DEV Community: Ramsudharsan Manoharan

Remove an image background free, right in your browser

Ramsudharsan Manoharan — Thu, 25 Jun 2026 12:57:59 +0000

I needed one product photo on a transparent background — a mug, lifted off the kitchen counter, ready to drop onto a clean store listing. Five minutes of work. Then the first site I tried wanted me to start a subscription before it would let me download the result at full resolution.

For one cutout. I closed the tab.

So I built the thing I actually wanted: drop a photo in, get a transparent PNG back, no account, no watermark, no card. That's ToolsTray's Background Remover, and I'm obviously biased toward it — but read this for one idea regardless of the tool you end up using: where the cutout is actually computed. That single detail is what lets a background remover be free and private in the same breath.

🎬 Demo: ToolsTray's Background Remover cutting a photo to a transparent PNG, entirely on-device — drag the slider to compare. Watch it on the original article →

The whole thing runs on your device

Most "remove background" sites upload your image to their server, run the model there, and bill you for the compute. That's why they need a subscription — someone has to pay for the GPUs.

ToolsTray flips that. A small AI segmentation model — a u2netp model, from the U2-Net family — runs inside your browser through an in-browser ONNX runtime. Your photo is handed to a model that's already sitting on your own machine; it never gets posted anywhere. The only thing that crosses the network is the model file coming down to you, once. Your image only ever moves between your tab and your screen. With no GPU running up a bill on my end, there's simply nothing to put a price on — that's the whole reason a tool this heavy can be free.

What you get back: a transparent PNG

You drop in a photo, wait a moment while it processes, and download a PNG with the subject cut out and the background gone — actually transparent, not a fake white box. That's the format you want for almost everything downstream: layering the subject onto a design, a thumbnail, a sticker, a banner, a marketplace listing.

If you'd rather not deal with transparency, you can composite the cutout onto a solid color instead — pick white for a clean product shot, or any color for a headshot backdrop — and export a finished flat image. Same flow, one extra choice.

First run downloads the model once, then it's cached

Here's the one wait worth knowing about. The first time you use the tool, your browser downloads the model and runtime — a few megabytes — before it can do anything. On a normal connection that's a few seconds, once.

After that, your browser caches the model. Every later cutout skips the download entirely and starts almost instantly. So the very first image feels a touch slower than you'd expect; the tenth feels immediate. It's a one-time tax, not a per-image one.

Tip: Doing a batch? Run your first image and let the model finish downloading before you queue up the rest. Once it's cached, the remaining photos process back-to-back with no fetch in between.

The honest tradeoff: fine hair and wispy edges

I won't oversell this. An on-device model is small by necessity — it has to fit in a browser download and run on your laptop in seconds — and that trades a little edge precision for the privacy and the price.

In practice: a clear subject with decent contrast — a product on a plain-ish surface, a person against a wall, a pet — cuts cleanly. But fly-away strands of hair, fur, or anything thin and wispy against a busy background is the hard case for any segmentation model, and a compact one will sometimes leave those edges a bit rough where a paid cloud service might nail them. If a pixel-perfect hairline matters for a hero image, a heavier paid tool can still win. For the everyday "I need this off its background, now," the gap rarely matters — and a higher-resolution, higher-contrast source photo closes most of it.

When it works best (and how to help it)

A few seconds of setup gets you a noticeably cleaner cut:

Contrast is everything. A subject that stands out from what's behind it cuts far better than one that blends in. A dark jacket against a dark couch is the worst case.
Go higher-res. More pixels on the subject gives the model more to work with, especially around edges. A cropped-in phone photo beats a tiny thumbnail.
One clear subject. The model finds the subject. A single mug, person, or animal in frame is the sweet spot; a cluttered scene with five competing objects is not.

Why I'd reach for this first

Most of the time you don't need a studio-grade matte — you need the background gone so you can get on with the listing, the slide, or the post. Free, instant after the first run, nothing uploaded, no watermark on the way out. For the once-a-week cutout that doesn't justify a subscription, that's the whole job done on your own machine.

Drop a photo in and see how clean the edge comes out on your image — it's the honest test, and it costs you nothing.

Try it — free, no signup, runs in your browser: Background Remover on ToolsTray

Compress a PDF under 1 MB for email — free, no upload

Ramsudharsan Manoharan — Thu, 25 Jun 2026 12:55:07 +0000

The upload form was blunt about it: "File must be under 1 MB." My scanned PDF was 6.4 MB. The job application wouldn't go a step further until I fixed that.

If you've hit the same wall — a portal that caps uploads at 1 MB or 2 MB, or an email that bounces a fat attachment — here's how to get a PDF under the limit in about thirty seconds, for free, and without handing your document to anyone.

I'll use ToolsTray's Compress PDF because I built it, but the why matters more than the which — so I'll explain what's actually making your file big and what a good compressor should do about it.

Why your PDF is so big (it's the images)

A page of text is tiny — a few kilobytes. What blows a PDF up to megabytes is images: scanned pages, phone photos, the screenshots in a slide export. A 12-page scanned contract is really twelve photos in a trench coat.

That points straight at the fix: squeeze the images and leave everything else alone.

The trap: compressors that flatten every page

Here's the honest tradeoff, and it's the thing a lot of "free PDF compressor" sites get wrong. Many shrink a PDF by turning every page into one flat image. The file does get smaller — but your crisp, selectable text becomes a blurry picture. You can't search it, you can't copy a line out of it, and it looks soft on screen.

A better compressor recompresses only the embedded images and copies the text and vector graphics through untouched. ToolsTray's Compress PDF re-encodes each photo with the MozJPEG encoder at the quality you pick, so the words stay sharp and selectable. That's the one thing I'd check for in whatever tool you choose.

Get under 1 MB in three steps

Open Compress PDF and drop your file in. Nothing uploads — it runs in your browser, which matters when the PDF is a contract or an ID.
Choose Target size and type your limit in KB — 1000 for 1 MB, or 200 if a form is stricter.
Download. The tool steps through progressively stronger compression and keeps the lightest result that still fits under your number.

Target-size mode in action: a 1.9 MB scan down to 325 KB (−84%), all on your device.

If you don't need an exact ceiling, skip Target size and pick Balanced — the right call for most reports and decks. Use Light when the photos must stay crisp, Strong when you simply have to make it small.

Tip: Email limits are far bigger than upload-form limits. Gmail and most providers cap attachments around 25 MB, but job portals, government forms, and visa sites often demand 1 MB — sometimes 200 KB. Compress to the smallest limit you actually need to clear, not smaller.

When it barely shrinks (and that's fine)

Compression isn't magic. If a PDF is mostly text, already optimized, or built from image types that can't be safely recompressed, there's little to remove — and a good tool tells you the smallest size it managed instead of mangling the file. ToolsTray's will never hand you a copy larger than the original.

If a text-only PDF is somehow huge, the weight is usually embedded fonts or junk metadata, not images — a different problem with a different fix.

Why "no upload" is the part I care about

When compression runs in your browser, your document never touches a server. For a payslip, a signed contract, or a passport scan, that isn't a marketing line — it's the difference between "trust this random website with my ID" and "the file never left my laptop." Open your browser's network tab while you use it and watch: nothing goes out.

It's also why it's free with no sign-up. There's no server doing the work to pay for — your own device does it.

Try it — free, no signup, runs in your browser: Compress PDF on ToolsTray

How to email a large, sensitive PDF without uploading it to compress?

Ramsudharsan Manoharan — Thu, 25 Jun 2026 07:21:02 +0000

A friend texted me on a Sunday night, half-panicking. She was applying for a flat, and the rental portal wanted her last three payslips as one PDF — under 2 MB. Hers was nine. She'd already found a "compress PDF" site, uploaded the file, and was watching the progress bar when she stopped and asked: "this is fine, right? it's got my salary and my account number on it."

It isn't, really — not a disaster every time, but not something I'd do with a payslip. And it's such a common trap, because the documents too big to email are almost always the ones you'd least want sitting on a stranger's server: payslips, bank statements, a scanned signed contract, ID proofs. Uploading those to the first search result is precisely the wrong instinct.

So here's how I deal with it instead, and why.

Why these are the PDFs that bounce

A bank statement is a few kilobytes of text wrapped around a logo and, if you scanned or photographed it, full pages saved as phone-camera-resolution images. The words weigh almost nothing; the pictures are the whole problem. That's also the good news — bring the images down to a sane size and the file drops hard while the text stays exactly as it was.

What the email limit actually is

The error messages are vague, so a quick reality check. Gmail caps attachments at 25 MB. Outlook.com is lower, around 20 MB. And there's a catch nobody mentions: attachments are re-encoded for transit and travel about a third larger than the file sitting on your disk, so a 20 MB PDF can trip a 25 MB limit. Plenty of company mail servers also quietly cap what they'll accept. Treat "under 25 MB" as "comfortably under 20."

Shrink it without uploading it

Here's the part that matters for a payslip: you don't have to send it anywhere to make it smaller. ToolsTray's Compress PDF does the whole thing in your browser — it opens the file on your device, re-encodes the images inside it, and rebuilds a lighter copy locally. Nothing leaves the tab. Drop the file in, choose Balanced, download. The text stays sharp and selectable because only the images are touched — which is exactly what separates it from tools that "compress" a PDF by flattening every page into a single picture.

When the form wants 100 KB, not 25 MB

The nastier version is the government form or job portal with a hard ceiling — 200 KB, sometimes 100 KB. I built the Target size option for exactly that, after a form rejected a scan of mine for being 240 KB without so much as hinting how far over the line I was. You type the limit; it keeps trying stronger compression until it finds the lightest result that still fits — or tells you the smallest it managed, if the file simply can't get there.

Why "in your browser" isn't just a slogan here

For a meme PDF, who cares where it gets compressed. For a document with your salary, account number, and home address on it, that's the entire question. A file you upload sits on someone else's server, in their logs, under their privacy policy, for however long they keep it. Processed on your device, there's nothing to leak — it never crosses the network.

When compressing won't help — and what to do instead

Honestly, it won't rescue every file. A PDF that's mostly text — a plain letter, a generated invoice — has almost no image data to drop, so it'll barely move, and the tool tells you so rather than pretend. (It also never hands you a file bigger than the one you started with.) If you're still over the limit, split it and send two emails, or rebuild it from fewer pages. And yes — a heavy cloud service with aggressive downsampling might squeeze out a little more than an on-device tool can. For a bank statement, that's not a trade I'd make.

My friend's payslips went from nine megabytes to about six hundred kilobytes in a few seconds, never left her laptop, and the portal took them on the first try. That's the bar I aim for: small enough to send, private enough to stop thinking about.

Dont decode JWT on random sites - verify if they are sending it to backend servers! How though?

Ramsudharsan Manoharan — Sun, 14 Jun 2026 18:06:53 +0000

A JWT usually carries who you are and what you're allowed to do. When you debug one, you tend to paste the whole token into the first "JWT decoder" search result — and a lot of those sites send that token straight to their own server to decode it. For a throwaway test token that's harmless. For a real access token from staging or production, you've just handed a stranger a working credential.

You don't have to guess which kind of site you're on. Here's how I check.

Why a JWT decoder can be risky

A JWT isn't encrypted — it's signed. The header and payload are just Base64URL-encoded JSON, so anything that can read the token can read every claim inside it: user id, email, roles, expiry, sometimes more. If the token hasn't expired, it's still usable. A decoder that ships your token off to a backend has, for a moment, a valid credential in its logs.

How to check what a decoder does with your token

Open your browser's dev tools, go to the Network tab, clear it, then paste a token into the decoder. Watch what happens:

No request fires → the page decoded it in your browser. Safe.
A request fires with your token in the URL or POST body → it went to their server.

That's the whole test. It takes about ten seconds and it's the only way to know for sure, regardless of what the marketing copy claims.

You can decode the payload yourself

A JWT is three Base64URL chunks joined by dots: header.payload.signature. The first two are just JSON. You can decode either part with any Base64 tool — no special "JWT" service required:

const [header, payload] = token.split(".");
console.log(JSON.parse(atob(payload.replace(/-/g, "+").replace(/_/g, "/"))));

Once you've seen that it's only Base64, the "send it to our server to decode" sites stop making sense. There's nothing on the server that your browser can't do.

Decode it locally instead

This is exactly why ToolsTray JWT decoder runs entirely in the browser — paste a token, read the claims, and nothing leaves the tab. It's the same convenience as the popular sites without the token ever crossing the network.

Before you paste: never share the signing secret

Reading the payload is safe. Verifying the signature is where people leak the thing that actually matters.

Verifying a JWT needs the signing secret or private key. Never paste that into a website — a secret is far more sensitive than a single token. Verify signatures locally, or in code you control.

WebAssembly turned my "static" site into a zero-backend app platform

Ramsudharsan Manoharan — Sat, 13 Jun 2026 18:10:28 +0000

For the longest time I treated "static site" and "does real work" as mutually exclusive. Static meant brochureware. Anything heavier like resizing an image obviously needed a server.

Then I built a site full of tools that do that heavy work and shipped the whole thing as static files on a CDN with no backend at all. The thing that made it possible — and changed how I think about web architecture — is WebAssembly.

I'll use one tool as the running example: an image compressor. Same lessons apply to everything else I've built, but one concrete case is clearer than a feature list.

The mental shift: the browser is the server

The old model: user uploads a file → your server does the work → sends the result back. You pay for that server, secure it, scale it, and the user's data takes a round trip through your infra.

WASM flips it. Ship the computation to the browser as a .wasm module and the user's device does the work. For the compressor, I use a WASM build of the same codecs you'd find in native tools (MozJPEG/WebP/AVIF). The "server" becomes a dumb file host. No upload, no round trip.

Benefit 1: client-side processing is a privacy feature you get for free

When you compress a photo and the file never leaves your device, "we don't see your data" stops being a privacy-policy line and becomes an architectural fact. There's no upload — you can watch the network tab and confirm it. I don't have a server that could see your photo, and that costs me nothing to provide.

Benefit 2: "fast loading" is more nuanced than it sounds — and mostly a win

People assume WASM = bloat = slow. The reality is more interesting.

The trick is that the page loads instantly and the WASM loads lazily. My pages are pre-rendered HTML, so they paint immediately, stay fully indexable, and keep Core Web Vitals green. The codec only gets fetched when you actually click "Compress."

// Nothing heavy ships in the initial bundle.
// The codec is dynamic-imported on first real use, then cached.
async function compress(file) {
  const { encode } = await import("@jsquash/webp"); // wasm loads here
  return encode(await fileToImageData(file));
}

After that first load it's instant — and there's no upload/download round trip. A 15 MB photo never travels anywhere; it's processed in place at near-native speed. A server tool would have you upload 15 MB, wait, and download the result. Locally it's often faster and the bytes never leave.

Benefit 3: it scales to infinity and costs almost nothing

This still feels slightly illegal. Hosting is a CDN serving static files. No compute to autoscale, no per-request cost. Whether 10 people or 100,000 people compress an image today, my bill is basically flat — because their CPUs did the work.

Now the parts that hurt (the honest section)

WASM is a game changer, but I collected scars. Budget for these:

First-run latency is real. The codec is a few hundred KB; heavier engines (ML models, etc.) are several MB. Lazy-loading hides it from everyone who never uses that tool, but the first hit waits while the module downloads and instantiates. I show an explicit "loading…" state so it doesn't feel broken.

Threads want SharedArrayBuffer, which wants cross-origin isolation. The fast multithreaded paths need COOP/COEP headers, and turning those on globally can break third-party embeds, ads, and analytics. I had to be deliberate about where I require isolation versus falling back to a single-threaded path.

Bundler/serving friction is constant. You'll fight your build tool over .wasm MIME types, worker output format, and keeping new URL('x.wasm', import.meta.url) resolution intact. It works, but it wasn't "npm install and go."

Memory and debugging are worse. A huge input can OOM the tab — and a WASM OOM isn't a graceful 500, the tab can just die, so you need size guardrails. And when something breaks inside the module, you don't get the comfortable JS stack trace; source-map support is still patchy.

Would I do it again? Without hesitation.

The cons are mostly one-time setup pain and first-load UX work. The benefits — privacy by architecture, no backend to run or secure, flat costs at any scale, near-native speed with no round trips — are permanent and compound.

The real unlock wasn't the compressor itself. It was realizing that "static" no longer caps what the product can do. It only caps where the code runs — and the browser turned out to be a perfectly good place to run it.

See it in action

If you want to poke at this for real, I put it into ToolsTray. Try the image compressor, open your network tab while you use it, and watch: the codec loads once, and your image never goes anywhere. That's the whole point.

Leave a like if you loved it! Happy to answer questions about the WASM setup in the comments.

How I auto-prioritize page content on a static site (no backend)

Ramsudharsan Manoharan — Mon, 08 Jun 2026 18:31:14 +0000

I run a static site with a growing pile of small tools on it. The homepage shows a "Popular" row near the top, and for a while I just hand-picked what went in it. That worked until it didn't — the picks went stale, my guesses about what people actually used were usually wrong, and every new tool meant re-ranking a list by hand.

The catch is that a static site has no server at request time to do the deciding. So people reach for one of two bad options: hardcode the order and let it rot, or bolt on a backend and stop being static.

There's a third option that's simpler than both: decide the order at build time, from real data, and bake it into the HTML.

One ranking, computed once

You don't need per-visitor personalization to do a good job here. A single global ranking — what's popular across everyone — gets you most of the value at zero runtime cost. Compute it during the build; the CDN serves plain HTML after.

The ranking is two signals added together: an editorial seed I set by hand, plus a traffic score from analytics.

export function rankByPopularity(
  tools: readonly ToolMeta[],
  gaScores: PopularityScores,
  limit: number,
): readonly ToolMeta[] {
  return [...tools]
    .map((tool) => ({ tool, score: tool.popularity + (gaScores[tool.slug] ?? 0) }))
    .sort((a, b) => b.score - a.score || a.tool.title.localeCompare(b.tool.title))
    .slice(0, limit)
    .map((scored) => scored.tool);
}

tool.popularity is the seed baked into each tool's metadata. gaScores[slug] is the real traffic number. New tools have no traffic yet, so ?? 0 lets the seed carry them until the data shows up — cold-start solved in one operator. The alphabetical tiebreak keeps the order stable so it never flickers between builds.

It's a pure function: no DOM, no fetch, no clock. That means I can unit-test the ranking with a fake gaScores object instead of rendering a browser to find out what came out.

Where the traffic number comes from

Once a week a small script hits the Google Analytics API, pulls 28 days of pageviews per tool page, normalizes the busiest to 1000, and writes a flat JSON file:

{ "age-calculator": 1000, "apr-calculator": 182, "base64": 91 }

Then I commit it. The build imports it like any other module — no network call in CI, no API key in the critical path. If GA is down, the build doesn't care; it uses the last committed numbers.

This is the part I'd argue about. Don't call the API at build time — commit the JSON. You get reproducible builds, traffic shifts you can read in a git diff, and rollback like any other file. The freshness you give up is a week, which does not matter for a popularity list.

Viola! You have a automatic prioritization mechanism that works in static sites.

See it in action here - ToolsTray, a free set of browser tools — the homepage ordering there is exactly this pipeline running. Explore it yourself and leave a like if you enjoyed it.

Toolstray - Free and fast web tools, no-signup, no-watermark

Ramsudharsan Manoharan — Sat, 06 Jun 2026 16:27:00 +0000

ToolsTray is a collection of 40+ small web tools — calculators, converters, generators and formatters — each built to do one job quickly and get out of your way.

Why I built it: I kept hitting the same friction — search basic, land on a slow page buried by paywalls (known after processing), watermark addition and forced logins for something that should take two seconds.

So I made the opposite: open the tool, use it, leave. No signup, no install, no paywall.

A few of the tools live today:

QR code generator (PNG/SVG)
Image compressor + resizer
Base64 / URL / HTML-entity encoders, hash + UUID generators, number-base converter
JSON formatter, regex tester
Loan/EMI, mortgage, SIP, compound-interest, percentage and age calculators

Tech: static Astro (islands) on Cloudflare, Tailwind v4 + Basecoat (no React) — adding a tool is adding one module, Typescript, Biome, Vitest.

Try it, bookmark it! It's young, so the catalog has gaps. What tool would you want next, and what felt rough?