DEV Community: chuanbuilds

I built 100+ file tools that never upload your data — here's how the browser-only architecture actually works

chuanbuilds — Sun, 06 Sep 2026 09:18:57 +0000

A couple of years into running small web tools, I got tired of the same pattern: every "free PDF tool" site either watermarked my file, throttled me after two uploads, or — worse — quietly sent the document to a server I didn't control. For something as sensitive as a tax form or a contract, that's a real problem.

So I built the opposite. UnTrackedTools is now 90+ tools (PDF, images, JSON, text, archives, dev utilities) that run entirely in your browser. The file never leaves the device. There's no upload step, no account, no backend processing the bytes.

This post isn't a product pitch. It's a walkthrough of how that architecture works in practice, what libraries do the heavy lifting, and the parts that bit me along the way — because "client-side" sounds clean until you hit a 400 MB PDF on a phone.

The mental model: file in, file out, nothing in between

Every tool follows the same shape:

<input type="file">
   ↓  File API reads bytes into memory (ArrayBuffer / Blob)
   ↓  a library mutates that in-memory data
   ↓  we hand the result back as a download

No fetch() to a server with your file. The libraries I use literally can't phone home with your data — they operate on ArrayBuffers sitting in tab memory.

Here's the actual skeleton most of the tools share:

const input = await file.arrayBuffer();      // bytes live in the tab now
const output = await transform(input);       // pure, in-memory
const blob = new Blob([output]);
const url = URL.createObjectURL(blob);
// trigger a download, then revoke the URL

That's the whole privacy story: the bytes are in the tab, the transform is synchronous local code, and the only thing that ever crosses the network boundary is the static JS bundle itself.

What actually does the work

I'm not reinventing file formats. I lean on battle-tested libraries that happen to run in the browser:

PDF → pdf-lib. Merge, split, rotate, add page numbers, compress — all by reading the PDF into memory and rewriting it client-side. The compressor is honest about its limits: it repackages the PDF with object streams (useObjectStreams), it doesn't re-encode embedded images. So a scanned PDF (already a flat image) won't shrink much. That's a real constraint, not a bug, and I say so on the tool page.
Images → compressorjs, which re-encodes through the Canvas API. No server round-trip, just the browser's own image pipeline.
Archives → JSZip for zipping files together in memory.
Passwords / random → the Web Crypto API (crypto.getRandomValues). This matters more than people think: a password generator built on Math.random() is generating guessable passwords. Mine pulls from the OS cryptographically-secure RNG.

If you want to see any of those in action, here are three that map directly to the libraries above:

Browser PDF compressor — pdf-lib, repackages locally
Image compressor — Canvas re-encode, no upload
Password generator — Web Crypto, client-only

The parts that bit me

"Client-side" is easy to say and harder to ship well. Three things caught me out:

1. Big files block the main thread.
Most of my transforms run on the UI thread. A 50 KB JSON formatter is instant. A 200-page PDF merge is fine. But push a 300 MB file and the tab freezes while the library churns — the user sees "page not responding" and assumes it's broken. The honest fix is a Web Worker so the parse happens off-thread, and I haven't rolled that out to every tool yet. I'm naming it because pretending it's all smooth would be a lie.

2. Browser memory is the real ceiling.
An ArrayBuffer lives in RAM. Desktop browsers handle a few hundred MB comfortably; mobile Safari gets unhappy much earlier, and there's no clean "out of memory" error — it just kills the tab. So the practical limit isn't my code, it's the device. I surface a size warning on the heavy tools instead of promising the moon.

3. Safari is its own country.
File System Access API (showSaveFilePicker) would let me write the result back without the download-dialog dance. Chrome ships it; Safari largely doesn't. So I target the lowest common denominator — generate a Blob, trigger a download — and it works everywhere, just one extra click on Apple devices. Not elegant, but it doesn't fail.

Why "private by architecture" beats "private by promise"

Most sites say they delete your file after an hour. You're trusting a server you can't see. The architecture here removes the question: there is no server step that touches your file, so there's nothing to delete, log, or leak. Privacy isn't a setting I flip on — it's a consequence of where the bytes live.

That also means no compliance theater, no "we never share your data" footer clause to litigate. The data never arrived.

If you're building something similar

The short version:

Reach for pdf-lib, compressorjs, JSZip, and Web Crypto before you write a byte of format code yourself.
Treat crypto.getRandomValues as the only acceptable RNG for anything security-related.
Plan for the main-thread freeze on large inputs — a Worker is the right call, I just owe you that work.
Test on mobile Safari early. It will be the constraint.

The fun part of this approach is that the "feature" (privacy) is free once the architecture is right. The hard part is everything around it: honest limits, memory ceilings, and browser quirks nobody puts in the landing-page copy.

If you want to poke at the tools or tell me which one should get a Web Worker first, the whole collection lives at untrackedtools.com.

I stopped trusting "free" Instagram font generators with my captions — so I built a browser-only one

chuanbuilds — Fri, 28 Aug 2026 02:57:53 +0000

Every time I want a slightly-less-boring Instagram bio, I fall into the same trap. I type my caption into some "free font generator," and somewhere between the input box and the copy button I realize I just pasted an unposted caption into a third-party site I've never heard of. Most of these tools upload your text to render it, which means my half-finished caption is now sitting on someone else's server.

So I built the one I actually wanted: an Instagram font generator that runs 100% in the browser. Type, copy, paste. Nothing leaves the tab.

Here's the part that's actually interesting if you write code: these "fonts" aren't fonts at all.

It's all Unicode

Instagram doesn't let you load custom fonts in a bio or caption. What these generators do is swap each letter for a look-alike character from the Mathematical Alphanumeric Symbols block (U+1D400 and up). "Bold" Latin isn't a bold typeface — it's the codepoint U+1D400 for 𝐀, U+1D41A for 𝐚, and so on.

So a generator is really just a small map: a → 𝐚, b → 𝐛 ... for each style. The whole thing fits in a few hundred bytes.

The core is a code-point offset

Each style is an offset into that block. Upper-case A–Z, lower-case a–z, and digits 0–9 each have their own base. A minimal version looks like this:

function styleText(input, base) {
  let out = '';
  for (const ch of input) {            // for...of walks code points, not UTF-16 units
    const code = ch.codePointAt(0);
    if (code >= 0x41 && code <= 0x5A) {        // A–Z
      out += String.fromCodePoint(base.upper + (code - 0x41));
    } else if (code >= 0x61 && code <= 0x7A) { // a–z
      out += String.fromCodePoint(base.lower + (code - 0x61));
    } else if (code >= 0x30 && code <= 0x39) { // 0–9
      out += String.fromCodePoint(base.digit + (code - 0x30));
    } else {
      out += ch;                          // leave spaces, punctuation, emoji untouched
    }
  }
  return out;
}

// Bold starts at U+1D400 (A), U+1D41A (a), U+1D7CE (0)
styleText("Hello 2026", { upper: 0x1D400, lower: 0x1D41A, digit: 0x1D7CE });
// => "𝐇𝐞𝐥𝐥𝐨 𝟐𝟎𝟐𝟔"

This offset trick only works for the contiguous styles (bold, italic, sans, mono, Fraktur…). Styles like bubble ⓐ or squared ② live in the Enclosed Alphanumerics block and aren't contiguous, so for those I just store a literal lookup table instead of computing an offset.

The for...of loop matters. If you index the string with input[i] you'll split emoji and astral characters into surrogate pairs and mangle them. codePointAt(0) plus iterating with for...of keeps emoji intact.

The lowercase h that broke my first build

This is the bug that cost me an hour. The italic style isn't perfectly contiguous: the code point you'd expect for italic lowercase h — U+1D44E + 7 = U+1D455 — is unassigned. Unicode already had ℎ (U+210E, the Planck constant symbol) as a slanted h, so it reused that instead of allocating a new slot. My offset math produced a blank/tofu box for every "h".

The fix is a one-line exception in the map. Same story for a few script/cursive capitals (ℋ, ℐ, ℛ, ℨ) — they live outside the main block too. If you build your own, hard-code those handful of exceptions or your output will have mysterious boxes.

Copy without a library

Copying is just the Clipboard API:

await navigator.clipboard.writeText(styled);

I add a document.execCommand('copy') fallback for older mobile browsers that don't support it yet, but on anything current the async API is all you need.

Why some phones show boxes

The stylized characters are real Unicode, but not every device ships a font that covers the Mathematical Alphanumeric Symbols block. That's why a style can look perfect on your laptop and turn into □□□ on a friend's older phone. The practical rule: test the exact style on the phone you'll post from, and if in doubt use bold or italic — those have the widest support. Also, don't style a whole paragraph; one word reads as intentional, a wall of 𝐛𝐨𝐥𝐝 reads as spam.

Why browser-only

The tool joins 100-plus other utilities in the UntrackedTools collection, and they're all client-side for the same reason: a caption, a draft bio, a config snippet — none of it should have to leave your machine to be transformed. No account, no upload, no analytics. Open the tab, style your text, close it.

If you post to Instagram (or TikTok/X — the characters paste anywhere Unicode goes), give the Instagram font generator a try. It's the one I use before every post now.

My Inverter Kept Tripping Until I Learned Running Watts Surge Watts

chuanbuilds — Thu, 13 Aug 2026 08:34:39 +0000

When I wired the electrical system in my campervan, I picked a 1000W pure-sine inverter. My loads summed to about 700W, so 1000W felt like comfortable headroom. Then I plugged in a 800W coffee maker and the inverter shut off instantly. Every time.

Turns out I'd sized for the wrong number.

There are two wattage figures for almost every device with a motor or compressor: running watts (what it draws steadily) and surge watts (what it yanks for a fraction of a second at startup). A coffee maker, a fridge compressor, a power tool, a vacuum — they all spike on startup, often 2–4× the running draw. My 800W coffee maker was surging close to 1600W the moment it switched on, and my 1000W inverter, rated for maybe 2000W surge for a few milliseconds, was not having it under a cold start.

The fix isn't just "buy a bigger inverter," either. Oversizing has its own cost: inverters are most efficient at mid-load, and a 3000W unit running a 50W fan wastes an ugly chunk of power just staying awake. You want headroom over the combined surge of everything that could run at once — not the running sum, and not a blind max.

So I listed every device I'd ever run off inverter power, with both numbers:

Device	Running	Surge
Fridge compressor	45W	120W
Coffee maker	800W	1600W
Laptop charger	90W	90W
Phone	18W	18W

Coffee + fridge starting together = ~1720W surge. That's the number the inverter has to survive for a second, not the 953W running total. I landed on a 2000W pure-sine unit and the trips stopped.

One more thing people skip: pure-sine vs modified-sine matters for anything with electronics in it. Cheap modified-sine inverters can fry sensitive gear or make weird noises in speakers. For a van where you're charging laptops and running a fridge controller, pure-sine is not optional.

I worked the whole thing through CampPowerCalc and their campervan inverter sizing guide — it walks through exactly this running-vs-surge step instead of just telling you to add up watts. The power inverter page on Wikipedia is a decent reference if you want the electrical background.

If your inverter trips on one specific thing, don't assume the device is broken. Check its surge draw first.

I Built a Tariff Lookup and Learned Why "Laptop" Is Not a Good Enough Word

chuanbuilds — Tue, 11 Aug 2026 09:07:50 +0000

Shipping side project hardware internationally made me sit down and actually read the Harmonized System for the first time. Ports and laptops, it turns out, do not live in the same subheading. A laptop is 8471.30 (portable automatic data processing machines); a port replicator or USB hub is a different heading entirely. Same desk, different tax rate.

The interesting engineering problem: tariff schedules are hierarchical — 2-digit chapter, 4-digit heading, 6-digit subheading — and the first six digits are shared across 200+ countries. That means one lookup table can serve the US, EU, UK and China, which is exactly the kind of data structure you want as a static export.

I documented the classification logic while building a laptop import duty reference and it's been the single most useful artifact for quoting customers accurate landed costs. The code is boring; the data model is the product.

I sized my camping battery wrong three times before I built a calculator for it

chuanbuilds — Tue, 11 Aug 2026 08:06:35 +0000

The first time I killed a battery at 2am, it was my own fault. I'd added up the watts on the stickers — fridge 45W, lights 10W, phone 12W — and rounded up to a 100Ah battery. What I'd missed is that "watts on a label" and "amp-hours in a box" aren't the same unit, and a compressor fridge spikes to 3–4× its running draw the second it kicks on.

The second time, I'd learned about watt-hours but forgot the inverter efficiency loss. The third time, I trusted the "up to 8 hours" claim on a product page that was measured at the fridge's minimum setting with nothing else running.

So I sat down and actually worked the math. The unit that matters is watt-hours — watts × hours. A 45W fridge running 24h isn't 45Wh, it's ~1,080Wh, and that's before the surge tax. Here's the tiny function I kept reaching for:

// watts pulled, hours run per day, plus a safety buffer
function dailyWh(devices, buffer = 0.2) {
  const base = devices.reduce((sum, d) => sum + d.watts * d.hours, 0);
  return Math.ceil(base * (1 + buffer));
}

const rig = [
  { watts: 45, hours: 24 },  // compressor fridge, runs near-constant
  { watts: 10, hours: 5 },   // LED lights
  { watts: 60, hours: 0.5 }, // phone + laptop top-up
];

console.log(dailyWh(rig)); // ~1354 Wh needed per day

That 1,354Wh is the number you actually size against — not the 67W sum of the stickers. Then you divide by your battery's nominal voltage to get amp-hours, and shave off ~20% so you're not parking a lithium cell at 100% discharge every night (which quietly halves its lifespan).

Once I'd done this by hand one too many times, I put it into a camping power calculator so I'd stop redoing the arithmetic on the back of a receipt. It walks the same path — list the devices, get the real Wh, then the battery and solar size that actually hold — and it's the thing I now send to friends instead of a paragraph of text.

Solar is the part people get backwards. A panel's "100W" is a lab number at perfect noon sun; you realistically collect 4–6 sun-hours a day, and only in summer. So a 100W panel is closer to 400–600Wh/day, not 2,400. If your rig eats 1,354Wh, one panel won't keep up — you need two, or a smaller fridge. The physics here is worth reading up on; watt-hour and photovoltaic system are the two pages I wish I'd opened before trip one.

The takeaway I keep repeating to myself: size for the peak and the real daily draw, not the sticker sum. A 20% buffer isn't optional padding, it's the difference between a battery that lasts the season and one you're replacing in the spring.

I finally stopped hand-indenting YAML. Here's the local converter I added to my toolkit

chuanbuilds — Fri, 07 Aug 2026 07:51:06 +0000

YAML is fine until it isn't. I keep a bunch of config files for side projects — CI pipelines, Docker compose, some Kubernetes manifests — and every time I need to move a JSON blob into one of them, I end up hand-converting it. That's how you get an hour of debugging a single missing space.

The annoying part is the tools. The converters you find by searching either upload your file somewhere or make you paste config into a third-party server. For a config file that contains API keys or internal URLs, that's a non-starter for me.

So I added a JSON ↔ YAML converter that runs entirely in the browser to my collection of client-side tools:

JSON to YAML converter

It does the two directions. Paste JSON, get YAML — or paste YAML, get JSON. Output is a one-click copy, nothing leaves the tab, no upload, no account. The conversion itself is standard library logic, not some ML thing, so what you get out is deterministic and lossless for valid input.

A quick example, because it's the kind of thing that looks trivial until you've been burned by it:

{
  "services": {
    "api": {
      "image": "registry.example.com/api:2.4",
      "ports": ["8080:80"],
      "environment": {
        "DB_HOST": "postgres",
        "DB_PORT": "5432"
      }
    }
  }
}

Hand-writing that as YAML means getting every level of indentation right:

services:
  api:
    image: registry.example.com/api:2.4
    ports:
      - 8080:80
    environment:
      DB_HOST: postgres
      DB_PORT: '5432'

One wrong space and your container just... doesn't come up. The converter removes the whole class of mistake — you work in the format you're comfortable in, and paste the result into the config.

It joins 100-plus tools in the Untracked Tools collection, all client-side for the same privacy reason. If you deal with config files at all, bookmark the converter — it's one of those "saved me on a Friday afternoon" tools.

I Built a Free Invoice Generator for Freelancers — Here's What Shipping Solo Taught Me

chuanbuilds — Thu, 30 Jul 2026 07:46:45 +0000

Like a lot of freelancers, I got frustrated with the same two bad options for sending invoices: hand-formatting them in Word, or signing up for a full accounting suite just to export a PDF.

So I built InvoiceFormly (https://invoiceformly.com/en/) — a free, browser-based invoice generator. Type your line items, drop in your logo, and download a clean PDF. No sign-up required for basic use.

The stack

Next.js 15 (App Router) deployed on Cloudflare Pages
PayPal Subscriptions for the optional Pro tier

The interesting bits

The trickiest parts were PDF rendering fidelity across browsers and handling tax/rounding correctly for multiple currencies. I kept the editor and the exported PDF layout in sync so what you see is exactly what gets sent.

Why I'm posting

I'm a solo indie developer and this is my first real SaaS. If you send invoices as a freelancer or run a small business, give it a try: https://invoiceformly.com/en/. I'd genuinely love feedback — especially from anyone who's solved cross-currency tax edge cases cleanly.

Happy to answer anything about the build in the comments.

I killed my campervan battery on night one. So I built a power calculator.

chuanbuilds — Fri, 17 Jul 2026 00:28:29 +0000

The first night in the van, I ran the fridge, charged a laptop, and left a light on. By 11pm the battery was dead and my phone was at 2%. I'd "estimated" my power needs the way you estimate how much pizza to order — vaguely, and wrong.

Turns out off-grid power isn't that complicated, it's just unforgiving if you guess. You need to know how many watts each thing pulls, for how many hours a day, and then size a battery and solar to cover it with some margin. The math is simple; doing it in your head at a campsite is not.

So I built CampPowerCalc. You tell it the appliances you actually run — fan, fridge, laptop, lights, water pump — and roughly how long each runs, and it works out the watt-hours, then sizes the battery and solar you'd want for vanlife, RV, or just a weekend off-grid. It uses real appliance draw data and straight physics, no "trust me bro" fudge factors.

The thing I like is it shows the gap. My first plan was way under-sized; seeing the number made me buy one bigger battery instead of discovering the shortfall at 2am in the woods. Different setups need different answers, so treat the result as a solid starting point and sanity-check it against your own gear — but it beats guessing and eating cold food.

If you're planning any off-grid power, it's here: https://camppowercalc.com/en/

I built a tiny import-duty calculator because the official ones are a maze

chuanbuilds — Thu, 16 Jul 2026 01:54:07 +0000

A few months ago a friend asked me to help figure out the tariff on a synthesizer he wanted to buy from a shop in Japan and ship to the US. Simple question, right? How much duty will this actually owe?

Six tabs and an hour later, I still didn't have a clean answer. The official sources exist — they're just buried in HS-code tables written for customs brokers, not humans. You're expected to know that a "synthesizer" maps to a specific harmonized code, then cross-reference the MFN rate, then remember that the rate depends on where the thing was made, not where you bought it.

So I built the thing I wished existed: TariffPedia. You type a product name or paste an HS code, pick the destination (US, EU, UK, or China for now), and it shows the representative MFN duty rate with a link straight to the official government source behind each number. No account, no paywall, no "sign up to see the result."

The part I cared about most was the source links. Anyone can quote a percentage; the useful thing is being one click from the page that actually says it, so you can verify before you rely on it. Last week I used it to sanity-check a camera lens I was importing, and the ten seconds it took beat the alternative of guessing and hoping the courier didn't slap on a surprise fee.

One honest caveat: these are representative MFN rates. The real number shifts with the product's country of origin, trade agreements, and the occasional exemption, and I'm not a customs broker. For anything with real money behind it, check the official source (TariffPedia links to it) or ask a licensed broker. I just wanted the guessing to stop for the small, everyday "wait, will this get taxed?" questions.

If you've ever stared at a customs form wondering what number goes where, it's here: https://tariffpedia.com

Digital Nomad Taxes: the basics before you panic

chuanbuilds — Tue, 14 Jul 2026 01:05:56 +0000

Everyone's "just work from Bali" story skips the boring part: you probably still owe tax. Being a digital nomad is a lifestyle, not a tax category. Here's what actually matters.

Where you're taxed

US citizens are taxed on worldwide income regardless of where they live.
Most others are taxed where they're a tax resident — commonly the 183-day rule.
Double-taxation treaties exist between many countries so you're not charged twice, but you must actually claim them.

Two levers US expats use

Foreign Earned Income Exclusion (FEIE) — excludes a chunk of earned income if you meet the residency test.
Foreign Tax Credit — offsets US tax by what you already paid abroad.

Don't DIY the hard stuff

If you've got income in three countries or a business structure, talk to someone. The cost of a mistake beats the cost of a consult.

I keep the plain-language version and simple calculators at Taxed Abroad — it's where I dump what I learn so I don't forget it. Use it to know which questions to ask, then confirm with a pro.

Two image tools I use that need zero install

chuanbuilds — Mon, 13 Jul 2026 12:00:50 +0000

I edit a lot of images for the web and I got sick of heavy desktop apps and sketchy upload sites. Two browser tools ended up in my daily rotation:

CompactJPG — shrink images without losing the plot

CompactJPG

Free online image compressor for JPG/PNG/WebP. The part I care about: it processes files locally in your browser, so nothing gets uploaded to some server. You drag in a photo, pick a level, and download a much smaller file that still looks fine. I use it before publishing any screenshot or product shot — shaves page weight without visible quality loss.

ClarifyPix — fix an image with AI

ClarifyPix

When a photo is blurry, low-res, or has a messy background, ClarifyPix runs AI on it to upscale, deblur, remove the background, or touch it up. You upload the photo for processing (deleted after an hour), and there's no free tier — a $1.99/week trial covers short projects. Handy for ecommerce listings, profile pics, or old photos you want to rescue.

Both are part of a small set of tools I keep at Untracked Tools. CompactJPG is free with no account; ClarifyPix needs an account and a paid trial. If your workflow still involves opening Photoshop to crop a JPEG, try the compressor first — it'll save you five minutes a day.

I shipped 8 small web tools for overseas users — here's the messy truth

chuanbuilds — Sun, 12 Jul 2026 02:18:37 +0000

A while back I stopped waiting for the one big SaaS idea and started building a bunch of small, boring tools that each solve exactly one problem. The theory: a portfolio of tiny sites, each monetized with ads or a subscription, compounding traffic over months instead of betting everything on a launch.

It's been equal parts fun and humbling. Here's what's live so far and what I actually learned shipping them.

The tools

Images & AI

CompactJPG — a free online image compressor. Files are processed locally in the browser, nothing gets uploaded, and it keeps quality better than I expected.
ClarifyPix — AI image fixes: upscale a blurry photo, remove a background, clean up an image. You upload a photo for processing (deleted after an hour); no free tier, but a $1.99/week trial.

Calculators (people love a good calculator)

Camp Power Calc — type in your devices (fridge, lights, phone, rice cooker) and it tells you the total draw, battery size, and solar panel you need so you don't lose power mid-trip.
Room Paint Calculator — punch in room size, doors, windows and get liters of paint plus a rough cost.
Fry Calc — temps, time, and oil for frying / air fryer based on ingredient and portion. Made it after one too many ruined batches.
Cold Plunge Calculator — dial in water temp, duration, and how much ice to add based on body weight and volume, so cold therapy stays safe.

Collections & money

Untracked Tools — the hub that lists every small tool I build in one place. No ads, instant load.
Taxed Abroad — tax guidance for expats and digital nomads: residency, treaties, filing obligations, in plain language.

What I learned

Specific beats clever. "Camp power calculator" gets searched. "Smart outdoor energy platform" does not. I wasted a week on a clever name for the paint tool before renaming it to what people actually type.

Distribution is the real product. Building took days; getting the first 100 visitors took longer. Submitting to directories, writing a few posts, and answering questions in the right places moved the needle more than any feature.

Calculators quietly convert. They're not flashy, but someone who just calculated their campsite battery need is a warm visitor. AdSense on these pages also performs better than on vague landing pages.

Don't fake the numbers. Early on I was tempted to post MRR screenshots I didn't have. Didn't. The builders who share real, including ugly, numbers are the ones people trust and link to.

Where this is going

The plan is to keep shipping one focused tool at a time, link them together through Untracked Tools, and let SEO + a few good backlinks do the slow work. No growth hacks, just consistent small bets.

If you're building small tools too, the hub above is the easiest way to see everything in one spot. Happy to compare notes with anyone on the same path.