DEV Community: bowen Tse

I Built 30 Free Tools That Run Entirely in Your Browser

bowen Tse — Sun, 25 Oct 2026 03:33:08 +0000

I Built 30 Free Tools That Run Entirely in Your Browser

Disclosure: I'm the founder of ToolkitLoop, the project this story is about. Everything below is my own experience building it.

The upload button that broke me

Last year I needed to convert a JPG to WebP. Simple task. Thirty seconds, tops.

I opened the first result on Google. It asked me to upload my image.

I hesitated. The image had a client's mockup in it. Nothing top-secret, but not mine to scatter across someone's S3 bucket either.

I opened the second result. It wanted an account before it would even show me the converter.

The third one worked without signup. But the moment I dropped the file in, I watched the progress bar crawl as my image traveled to a server somewhere, got processed God-knows-where, and came back.

For a format conversion. Something my laptop could do in milliseconds.

That was the moment the idea lodged itself in my head and wouldn't leave: why does a trivial computation need my file at all?

The insight: your browser is a supercomputer

Here's the thing most people never think about. The device you're reading this on can run circles around the servers that hosted the entire web in 2005.

Modern browsers ship with staggering capability. Canvas manipulation. WebCrypto. Web Workers for background processing. The File API for reading local files without ever touching a network. WebAssembly for near-native speed.

A JPG-to-WebP conversion? The browser does it natively with createImageBitmap and canvas export. A JSON formatter? That's string manipulation — microseconds. A QR code generator? Pure math, rendered to canvas.

None of these need a server. They never did. The server was there because it was easier for the developer, not better for the user.

Servers mean infrastructure bills. Infrastructure bills mean the tool needs to make money. Making money means ads, or paywalls, or harvesting your uploads as training data, or all three.

Remove the server and the whole rotten incentive chain collapses. No uploads means nothing to leak, sell, or breach. No accounts means nothing to track. No backend means the marginal cost of one more user is effectively zero — so the tool can actually be free, forever, without a catch.

That's the bet I decided to make.

Building it: browser-first as architecture, not marketing

"Browser-first" gets thrown around a lot. For ToolkitLoop, it's a hard architectural constraint, not a tagline.

Every tool runs 100% client-side. The page loads, and from that point on, you could pull your ethernet cable and everything keeps working. Your files never leave your device. There is no API endpoint receiving your data because there is no API.

This constraint shaped every technical decision.

State lives in the page, not in a database. Heavy work goes to Web Workers so the UI never stutters. Anything that looks like it needs a server — I either found a client-side way or cut the feature.

The upside goes beyond privacy. These tools are fast. No round trips. No spinners waiting on a server. No rate limits because there's no shared resource to protect. And they're resilient — no backend means no backend outages.

The downside is real too, and I'll be honest about it. Some things genuinely need servers: anything collaborative, anything that needs to persist across devices, anything with serious compute. I don't pretend browser-first solves everything. It solves the large, neglected category of personal utility tasks — the format conversions, the calculators, the generators, the validators — where a server was always overkill.

A concrete example: the image converter pipeline

Since this is HackerNoon, let me show rather than tell. Here's roughly what happens when you drop a JPG into the converter:

The File API reads the bytes locally. createImageBitmap decodes it — using the browser's native, hardware-accelerated codecs, the same ones that render every image on the web. The bitmap goes to an offscreen canvas. Then canvas.convertToBlob({ type: 'image/webp', quality: 0.85 }) re-encodes it.

That's the whole pipeline. Four steps, zero network calls, and it runs in a Web Worker so the tab stays responsive on a 50-megapixel panorama.

The QR code scanner is my favorite example of the philosophy paying off. It uses getUserMedia to open your camera, grabs frames to a canvas, and runs the detection algorithm right there in the page. Your camera feed never leaves the device — which, when you think about it, is the only sane way to build a QR scanner. The alternative is streaming your camera to a stranger's server. People do this every day without blinking.

For developers reading this: the constraint forces a useful discipline. Every feature request gets filtered through one question — can this run on the client? If yes, it ships without any infrastructure work. If no, it gets cut or redesigned. There's no "we'll add a microservice for that" escape hatch, which means the architecture can't drift into complexity. The codebase stays boring in the best possible way.

Thirty tools, one philosophy

I didn't start with thirty. I started with one — a character counter, built for a friend who kept blowing past comment length limits on forums.

Then a QR code scanner. Then a JSON formatter. Each one took the same shape: open the page, do the thing, close the tab. No friction.

Somewhere around tool fifteen, I realized the collection itself was the product. Nobody wakes up wanting "a tools website." They wake up wanting to convert a timestamp, or validate a regex, or split a bill. The job-to-be-done is atomic. So the site is organized around that: thirty independent tools, each one a complete answer to a specific "I need to…" moment.

The current lineup spans the boring-but-essential: percentage calculators, unit converters, currency converters, a tip calculator that splits bills penny-perfect. And the developer-flavored: diff checker, regex tester, JSON formatter, barcode generator, favicon generator, case converter.

Boring is a compliment here. These are the tasks you do a hundred times a year and never think about — until the tool you trusted asks for your email address.

The distribution problem (being honest)

Here's where the build-in-public honesty kicks in: building the tools was the easy part. Getting anyone to find them is the actual hard problem.

I'm a solo founder. No funding, no marketing team, no ad budget. So I'm running the playbook available to me: make each tool page genuinely excellent for its specific query, and let search do the work.

Part of that is a deliberate experiment I ran recently: 250 programmatic long-tail pages — currency pairs, unit conversions — each one a real page with real computed content, not thin doorway spam. It's too early to call it a success or failure. I'm watching the data for 4–6 weeks before deciding whether to expand it to other languages.

That's the unglamorous truth of indie hacking. You ship, you measure, you decide. No growth hacks. Just compounding small bets.

I'm also writing about the process — tutorial-style articles on dev.to, Hashnode, and now here on HackerNoon. Not "10x your productivity" listicles. Actual how-tos with code, aimed at people who build things. If that sounds like you, we're probably going to get along.

Why free is sustainable (the math)

People always ask where the catch is. Fair question — "free" on the internet usually means you're the product.

Here's the math. A traditional tool site pays for servers, bandwidth, storage, and the engineering to keep uploads secure. Every user costs money. So every user has to make money, somehow.

My cost structure is a static site on a CDN. Whether ten people or ten million people use the tools, my marginal cost per user is essentially zero — the compute happens on their devices, the bandwidth is static assets cached at the edge.

That's what makes "free with no catch" an honest statement rather than a growth-hacking slogan. I'm not subsidizing your usage while I figure out monetization. The architecture genuinely doesn't need your money to serve you.

Could I still add a paid tier someday? Sure — for power features that also run locally, or for teams. But the free tools don't need to convert you into a paying customer to justify their existence. That's a structural difference, not a pricing tactic, and it's the reason I can promise the free tier isn't going anywhere.

What's next

The roadmap is driven by a simple filter: is this a task where a server is overkill?

A Core Web Vitals checker is in the works — it queries Google's public CrUX API directly from your browser, no backend proxy, with historical trend data the existing checkers don't show. Same philosophy, new territory.

Longer term, I want to prove that the browser-first model can sustain a real business without compromising. Maybe that's a pro tier for power features that still run locally. Maybe it's something I haven't thought of yet. The constraint — never touch user data — is non-negotiable. The business model has to fit inside it, not the other way around.

Try it, break it, tell me

Everything is at toolkitloop.com. No signup. No tracking. Open a tool, use it, close the tab.

If something's broken or missing, I genuinely want to hear about it — solo founders don't get bug reports unless they ask. You can find me here on HackerNoon or on X.

And if you've ever stared at an upload button and thought "why does this need my file" — now you know you're not alone. I built thirty tools out of that exact frustration.

I Built a Client-Side JSON Formatter: 5 Lessons for Devs

bowen Tse — Sun, 25 Oct 2026 03:00:29 +0000

Every developer has pasted a minified API response into a formatter and stared at one long line, wondering where the nesting went wrong. I built a client-side JSON formatter to solve that exact moment, and the work taught me more about JSON than years of casually using it. Disclosure first: I built this tool — it is part of ToolkitLoop, my collection of free browser tools — so this post is both a tutorial and a build log.
Here are the five lessons, each with code you can run today.

1. JSON is stricter than JavaScript, and that is the point

JavaScript lets you write {name: 'Alex', active: True,} and nobody complains until you try to parse it as JSON. JSON does not allow unquoted keys, single-quoted strings, Python-style booleans, trailing commas, or comments. Each of those is a feature of some other language, not a bug in your data — but JSON rejects all of them.
The core formatting operation is just two lines:

const data = JSON.parse(rawText);
const pretty = JSON.stringify(data, null, 2);

JSON.parse enforces the strict rules. JSON.stringify with an indent of 2 produces the readable output. Everything else in a formatter — the tree view, the search box, the repair button — is help around those two lines. When you understand that, debugging gets simpler: if JSON.parse throws, the document is invalid, full stop. No formatter setting will change that fact; only fixing the text will.
A practical habit follows from this: keep your parse and your repair separate. Parse first to learn whether the document is valid. Repair only when you know exactly which predictable mistake you are fixing. Mixing the two steps hides the error you most need to see.

2. Safe repair means a small, honest list

The most tempting feature in a formatter is an aggressive "fix everything" button. I resisted it, and here is why: a repair that guesses can silently change meaning. If a tool invents a missing field, reorders data, or converts a type to make parsing succeed, you may ship a document that parses cleanly and behaves wrongly.
The repair list I kept is deliberately small and predictable:

trailing commas removed
single-quoted strings converted to double quotes
simple unquoted keys quoted
True, False, and None converted to true, false, and null
comments stripped
common AI code fences stripped That is it. Each item is a copy-and-paste mistake with one obvious correction. Anything outside that list stays an error, and the user sees the error instead of a silent guess. The tool page says this plainly: review repaired output before using it in production. That sentence is not legal padding. It is the contract that makes automatic repair trustworthy. Try it with the classic broken example:

// Input (invalid JSON)
const broken = `{
  name: 'Alex',
  active: True,
}`;

// After limited repair, this parses:
const fixed = `{
  "name": "Alex",
  "active": true
}`;

console.log(JSON.parse(fixed));
// { name: 'Alex', active: true }

Notice what did not change: the values, the field names, and the order. A good repair preserves all three.

3. Readability is a debugging tool, not cosmetics

Formatting is often treated as tidying up, but for JSON it is genuinely a debugging step. A minified response hides nesting errors. An indented response shows them. When every field sits on its own line, a field under the wrong parent jumps out. When a tree view lets you collapse a branch, you can check one subtree without losing your place in a thousand-line document.
Two reading aids earn their place in any formatter. First, a tree view: it turns a flat wall of text into collapsible structure, which matters most when a response contains nested arrays of objects. Second, a key search: it answers "where is the error code in this response?" without manual scanning. Neither changes the data. Both change how fast you find a problem.
Indentation choice matters less than consistency. Two spaces is the common default, but matching your project's style matters more than the number itself. A formatted document pasted back with the wrong indentation creates a noisy diff that hides the real change. Format with your project's indent, then copy.
You can try the workflow here: JSON Formatter (https://toolkitloop.com/json-formatter). Paste a response, format it, switch to the tree view, and search for one key. The whole loop takes under a minute, and it is the loop I use when an API response does not look right.

4. Never upload data you would not paste into a chat

This is the lesson that changed how I think about tool architecture. A server-side formatter receives your text, processes it, and returns a result. For public sample data, that is harmless. For a production API response, a config file, or an AI answer containing project details, that round trip creates a copy of your data somewhere else — in transit, in a log, or in a processor you do not control.
A client-side formatter avoids that round trip entirely. The tool page puts it simply: everything stays in this browser, and the text is not uploaded to ToolkitLoop. That design choice removes a whole class of exposure, and it costs nothing in features for formatting, validation, repair, tree viewing, or search. All of those run in JavaScript on your device.
That does not make any formatter a vault. My rule, and the rule I recommend, is the same for every online tool: redact real secrets before you paste. Replace an API key with REDACTED, format the document, check the structure, and put the real value back only in your own secure system. Local processing plus redaction is a much stronger combination than either habit alone.
If you take one habit from this post, take that one. The next time you are about to paste a production response into a random formatter, pause and ask: does this tool need to receive my data at all? For formatting, the answer is no.

5. Syntax is not schema, and confusing them wastes hours

A document can be perfectly valid JSON and still be rejected by your API. That is not a contradiction. JSON syntax answers one question: does this text follow JSON's punctuation and value rules? A JSON Schema answers a different question: does this data match the expected contract — required fields, permitted types, allowed values, and formats?
The formatter validates syntax and helps you inspect shape. It does not claim to validate a JSON Schema, and that distinction is stated on the tool page for a reason. When a clean document is rejected, the debugging order should be:

Format and confirm the syntax is valid.
Check the schema: is a required field missing?
Check types: is a number where a string is expected, or vice versa?
Check values: is a status outside the allowed list? Skipping step 2 and re-formatting the same document five times is a familiar waste of time. I have watched developers do it, and I have done it myself. Naming the two checks separately — syntax first, schema second — ends that loop. The companion tool makes the split explicit: the formatter makes valid JSON readable and repairs a few common mistakes, while the JSON Validator focuses on finding and explaining syntax errors. Use validation when you do not know why a document fails. Use formatting when you know it is valid and just cannot read it.

Putting it together

The full workflow is short enough to remember:

Redact secrets, then paste.
Parse to learn whether the document is valid.
Repair only the small predictable list, then review the output.
Format with your project's indentation.
Read the result once, checking parents, closures, and types.
If a clean document is still rejected, check the schema, not the syntax. That is the whole tutorial, and it is also the design of the tool: format, validate, and fix JSON in your browser (https://toolkitloop.com/json-formatter). Free, no signup, and your text never leaves your device. Disclosure again, because it matters: I built this tool, so I am biased toward client-side design. Try the workflow on your own ugliest API response and judge it by the result, not by this post. What is your rule for pasting production data into online tools — redact first, use local tools only, or something else? I am curious where other developers draw the line.

I Built a Zero-Backend M3U8 Player: 5 HLS Lessons for Devs

bowen Tse — Fri, 23 Oct 2026 03:26:09 +0000

Paste a .m3u8 URL into Chrome's address bar and the browser just downloads a text file. No error, no player — a download. That tiny moment of confusion is where most developers first meet HLS, and it usually leads to the same question: why does the video format that powers most of the internet's live streaming feel invisible to my browser?

I got annoyed enough by this to build a zero-backend M3U8 player that runs entirely in the browser, with a manifest inspector and a diagnostics panel so you can see why a stream fails instead of staring at a black box. Full disclosure: it's my tool, free, no signup, and every URL you paste stays in your tab.

Here are the five things I learned that I wish someone had told me before I started.

1. M3U8 is not a video format — it's a shopping list

The single most important mental model: a .m3u8 file is a playlist, not media. It's UTF-8 text (that's the "8" in M3U8) listing segment URLs plus metadata. A master playlist looks roughly like this:

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=800000,RESOLUTION=640x360
http://example.com/low.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720
http://example.com/hi.m3u8

Each media playlist then lists 6–10 second segments. The player downloads segments one at a time and stitches them together. Adaptive streaming — the reason your livestream doesn't freeze when your Wi-Fi dips — is just the player choosing which playlist's segments to fetch based on measured throughput.

Once you see it this way, "playing an HLS stream" decomposes into: fetch playlist → parse → fetch segments → remux → decode. Every HLS player, from Safari to VLC to a web page, is doing exactly this.

2. Your browser already knows how to play the video — it just can't read the menu

Here's the surprise: Chrome, Edge, and Firefox are perfectly capable of decoding the segments. They contain H.264/AAC in an MPEG-TS container, and browsers can demux and decode that just fine through the Media Source Extensions (MSE) API.

What browsers (except Safari) lack is the playlist layer: nobody wrote the code that parses #EXT-X-STREAM-INF, resolves relative segment URLs, and manages the quality-switching state machine. That's what hls.js does in JavaScript — about 2,000 lines of library code that fill the gap Apple left.

import Hls from 'hls.js';

const video = document.getElementById('video');
if (Hls.isSupported()) {
  const hls = new Hls();
  hls.loadSource('https://example.com/stream.m3u8');
  hls.attachMedia(video);
  hls.on(Hls.Events.MANIFEST_PARSED, () => video.play());
} else if (video.canPlayType('application/vnd.apple.mpegurl')) {
  // Safari: native HLS, no library needed
  video.src = 'https://example.com/stream.m3u8';
}

That ~12 lines is the core of nearly every browser-based HLS player in existence. The rest is UI, error handling, and diagnostics.

3. CORS is the #1 reason "it works in VLC but not in my browser"

This is the trap nobody warns you about. VLC is a desktop app — it can fetch any URL on the internet. A web page cannot: the browser's same-origin policy blocks cross-origin fetches unless the server sends back an Access-Control-Allow-Origin header.

HLS segments live on someone else's server. If that server doesn't allow cross-origin requests, hls.js will fail with a network error and there's nothing client-side code can do about it. The same link plays fine in VLC.

This is also why you should never judge a stream's health from a single environment. My player surfaces this distinction in its diagnostics: a failed fetch with no CORS headers gets flagged as a CORS restriction, not a "broken stream." If you're shipping streams, the fix is on the server side — send the header and your streams suddenly work in every web player.

4. A manifest inspector is worth more than a play button

The second most common failure mode after CORS is the dead URL. HLS links with tokens expire — sometimes within hours. Geo blocking returns 403s. DRM-protected playlists need license handshakes a generic player will never perform.

A player that only has a play button turns all of these into the same symptom: nothing happens. That's why I put a manifest inspector front and center in the tool: it shows whether the playlist itself loads, what variants it advertises, and what the HTTP response actually was. A 403 with a body mentioning region restrictions is a different problem than a 404 on the playlist or a playlist whose segments 404 one by one.

If you're debugging streams for a living — testing that your CDN config, token auth, or multi-bitrate ladder is correct — this kind of visibility is the difference between "it doesn't work" and "the 1080p variant's segments return 403 from edge node X." The player never bypasses access control; it just reports what the network actually said.

5. Zero backend is a feature, not just a cost saving

Every byte of a video stream going through my server would be a bandwidth bill and a privacy liability. The whole point of the architecture: the browser fetches the playlist and segments directly from the source. My tool never proxies, downloads, or records anything — the URL you paste, any local .m3u8 file you open, and the diagnostics all stay in your tab.

This has a real side benefit for users who test sensitive streams: you can paste an internal staging URL without wondering whether some server is logging it. The page says it plainly — "Your URL, local file and diagnostics stay in this browser" — and it's architecturally true, not just a policy promise.

One genuine edge case this design forces you to handle: local .m3u8 files with relative segment paths. Browsers won't let a page guess where segment-1.ts lives, so the player asks for an explicit HTTPS base URL. It's a small UX wrinkle imposed by the platform's security model, and it's the honest way to do it.

Takeaways

If you're building anything with video on the web, remember the decomposition: HLS is playlists + segments + MSE. The playlist layer is the only part your browser is missing, and hls.js fills it in about 12 lines of code. When streams fail, check CORS first, tokens second, and always read the actual HTTP response before blaming the player.

And if you just want to poke at a stream without writing code, the player I built is there — paste a URL, watch the manifest inspector tell you what's really going on: toolkitloop.com/m3u8-player.

What's the weirdest stream-debugging session you've had? I've seen geo-blocked test streams that "worked on my machine" because the dev was on a VPN and forgot. Tell me yours in the comments.

Compress Any Image to Exactly 100KB: A Binary-Search Trick

bowen Tse — Wed, 21 Oct 2026 03:04:48 +0000

Every web developer has lived this exact loop:

A form says "upload must be under 100KB". You export your image at quality 80. It's 340KB. You drop to 60. It's 61KB — nice. Or it's 134KB — not nice. You try 55. It's 98KB. Close enough. Ship it.

Ten minutes of blind guessing to satisfy one number. And the number you were actually asked about — the file size — was never under your control. You were tuning a proxy (the quality slider) and hoping the size landed somewhere acceptable.

There's a better primitive, and it works every single time.

Why the quality slider is the wrong primitive

Here's the uncomfortable truth about the quality slider: the same quality value produces wildly different file sizes on different images. A flat illustration at quality 80 might be 40KB. A noisy smartphone photo at quality 80 might be 900KB. A gradient-heavy hero image, something else entirely.

The quality number controls how aggressively the encoder throws away detail, not how many bytes come out. The mapping from quality to bytes depends entirely on the content of the image — its entropy, its noise, its colors. It's a function you can't evaluate without running the encoder.

So the classic workflow — pick a quality, check the size, adjust, repeat — is just manual search. You are acting as a human binary-search over the quality axis, one export at a time. That's not a skill issue; it's a bad primitive. The tool gave you the wrong input.

The fix is to invert the problem.

Think target-first

Instead of asking "what quality should I use?", ask: "what is my byte budget, and what's the highest quality that fits inside it?"

That's it. The input is a target — 100KB — and the output is the best-looking image that fits. This is exactly what "target-first compression" means, and it's straightforward to implement because the relationship between quality and output size is monotonic: lower quality never produces a bigger file (for lossy encoders). Monotonic function? Then you can binary-search it.

The algorithm:

Draw the image to a canvas, capping the long edge at a sane size (say, 1920px — there's no point compressing a 6000px photo to 100KB, it will look terrible).
Binary-search the quality axis over ~8 iterations of canvas.toBlob, keeping the best blob that fits the budget.
Download the winner.

Eight iterations is a good number: 2^8 = 256 quality steps, finer than any slider you've ever dragged, and it runs in milliseconds because each iteration is a single encode.

Why does binary search work here? Because the encoder is monotonic in quality: raising quality never shrinks the output. That one property turns a guessing game into a solved problem. (A purist will note that monotonicity can wobble at the extreme low end of some encoders — in practice, the "bank the best fit" pattern absorbs that: a wobble might cost you a slightly suboptimal answer, but never an invalid one. You'll always ship a file that fits.)

Here's the whole thing, drop-in ready:

// Binary-search the highest quality whose output fits `targetBytes`.
// canvas: HTMLCanvasElement or OffscreenCanvas, mime: "image/jpeg" or "image/webp".
async function compressToTarget(canvas, mime, targetBytes, iterations = 8) {
  const blobOf = (q) =>
    new Promise((resolve) => canvas.toBlob(resolve, mime, q));

  let lo = 0.0, hi = 1.0;
  let best = await blobOf(0); // lowest quality always fits — worst case fallback
  for (let i = 0; i < iterations; i++) {
    const mid = (lo + hi) / 2;
    const blob = await blobOf(mid);
    if (!blob) break; // encoder refused this setting
    if (blob.size <= targetBytes) {
      best = blob; // fits — bank it, aim higher
      lo = mid;
    } else {
      hi = mid; // too big — go lower
    }
  }
  return best;
}

// Usage:
const blob = await compressToTarget(myCanvas, "image/jpeg", 100 * 1024);
console.log(`Final size: ${(blob.size / 1024).toFixed(1)} KB`);

A few notes for the copy-pasters:

canvas.toBlob takes quality as a float from 0 to 1 — not 0–100.
This trick applies to lossy formats (JPEG, WebP). PNG is lossless: the quality parameter is ignored, so the search collapses immediately and you get one answer.
If even quality 0 exceeds your budget, your image is too big dimensionally — halve the canvas resolution and search again. Bytes follow pixels roughly linearly, so one resize usually does it.
best always holds a valid answer: you'll never get undefined back, even if nothing at reasonable quality fits.

That's the entire technique. No libraries, no server, no guessing.

Don't want to write code? I built this for you

Full disclosure: I built this free tool — Compress Image to 100KB.

It does exactly what the code above does, but wrapped in a UI: type in your target size, drop in (or paste from clipboard) a JPG, PNG, or WebP, and the browser searches for the highest quality that fits your budget. The result card always shows the actual output size, so there's no guessing loop. Everything happens locally in your browser — your images are never uploaded anywhere — and it's free with no signup.

What I like most about having it as a tool rather than a snippet: it removes the "is this good enough?" hesitation. When the byte budget is enforced automatically, you stop compressing defensively — you don't nuke an image to quality 55 "just to be safe" when quality 72 would have fit fine.

It's the tool I wish every upload form had next to its "max 100KB" requirement.

The real question

The technique transfers everywhere: thumbnails for a listing page, avatars with a strict size cap, email attachments that must stay under some corporate limit, or just keeping a portfolio page fast. Once you think in byte budgets instead of quality sliders, you stop exporting-and-checking entirely.

So here's my question for you: what byte target do you actually ship images at? Is 100KB still the magic number because of form limits, or have you moved to something else — 200KB? 500KB? And do you compress at upload time, at build time, or with a CDN? Drop your number and your setup in the comments — I'm curious how the real world differs from my 100KB tunnel vision.

I Built a Client-Side Favicon Generator (60-Second Tutorial)

bowen Tse — Mon, 19 Oct 2026 03:12:37 +0000

Your logo looks great at 1200px. At 16x16, it's a smudge.

That's the entire favicon problem in one sentence. Every site needs that tiny tab icon, and the standard workflow for making one is embarrassingly bad: upload your logo to some generator, create an account, wait in a queue, download a watermarked PNG, realize it's a single 32px file with no ICO, no Apple touch icon, no manifest — and start over.

I got tired of that loop, so I built a favicon generator that runs 100% in the browser: type 1–3 initials or pick an emoji, set colors, preview at real tab sizes, and download the full pack (ICO, PNGs, Apple touch icons, PWA manifest). No upload, no signup, no watermark. This post is the 60-second tutorial plus the one canvas technique that makes it all work.

The 60-second workflow

1. Type initials or pick an emoji. Two bold letters ("TK") survive 16px far better than a full wordmark. An emoji works too — it gets rendered into icons at every size, 512px down to 16px.

2. Set background and foreground colors. Contrast is everything at small sizes. Pick a shape (rounded square is the safe default) and keep the default 18% padding so the glyph doesn't touch the icon edges.

3. Check the tiny preview. This is the step most generators skip: look at your design at 64, 48, 32, 24, and 16px side by side. If the 16px version fails, simplify — thicker strokes, fewer characters, more contrast. A favicon that only looks good at 64px fails at its one job.

4. Download the pack. One click gives you the multi-size ICO, PNGs, Apple touch icons, site.webmanifest, the HTML snippet, and install notes for plain HTML, Next.js, and React/Vite.

5. Paste three lines into your <head>:

<link rel="icon" href="/favicon.ico" sizes="any">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">

Then hard-refresh — browsers cache favicons aggressively, and a stale cache is the #1 reason "my new favicon isn't showing."

The canvas technique: legible glyphs at every size

The core trick is simple: render once at a large master size, then downscale. Text drawn directly at 16px is at the mercy of the browser's font rasterizer; text drawn at 512px and scaled down keeps clean edges. Here's the essence:

function renderFavicon(text, bg, fg, padding = 0.18) {
  const S = 512; // master size
  const canvas = document.createElement('canvas');
  canvas.width = canvas.height = S;
  const ctx = canvas.getContext('2d');

  // Background: rounded square with padding
  const pad = S * padding;
  ctx.fillStyle = bg;
  ctx.beginPath();
  ctx.roundRect(pad, pad, S - pad * 2, S - pad * 2, S * 0.22);
  ctx.fill();

  // Foreground: centered initials, sized to the padded box
  const box = S - pad * 2;
  ctx.fillStyle = fg;
  ctx.textAlign = 'center';
  ctx.textBaseline = 'middle';
  ctx.font = `700 ${box * 0.52}px system-ui, sans-serif`;
  ctx.fillText(text, S / 2, S / 2 + box * 0.04);

  return canvas;
}

// Downscale the master to every target size
for (const size of [16, 32, 180, 192, 512]) {
  const c = document.createElement('canvas');
  c.width = c.height = size;
  c.getContext('2d').drawImage(master, 0, 0, size, size);
  const png = c.toDataURL('image/png'); // one per size
}

Three details worth stealing for your own projects:

roundRect + padding keeps the glyph optically centered and clear of the edges where launchers clip. The 18% default is a good starting point.
The + box * 0.04 vertical nudge compensates for font metrics — most fonts render slightly high when centered by middle baseline. Without it, initials look like they're floating.
One master, many downscales beats re-rendering text per size. drawImage downscaling from 512px produces cleaner 16px output than drawing text at 16px directly.

(Emoji favicons use the same pipeline — draw the emoji glyph with fillText at master size and downscale. Canvas handles the rasterization; you handle the sizes.)

ICO vs PNG vs SVG, in 30 seconds

ICO is the broadly compatible workhorse — one file bundles multiple sizes, every browser understands it. Your baseline.
PNG serves specific sizes: Apple touch icon (180x180), PWA manifest (192/512). Crisp, universal.
SVG only when your source is a true, safe vector. Wrapping a raster logo in SVG gains nothing.

The full checklist: 16x16 + 32x32 (tabs, inside the ICO), 180x180 (iOS), 192 + 512 (PWA manifest).

Two gotchas before you ship

Dark mode tabs. A dark mark vanishes on dark browser chrome. Preview on both themes before exporting — a light rounded-square background behind a dark glyph survives either.

Google controls final rendering. Google shows favicons in mobile search results, but on its own schedule. Keep the icon square, stable, and crawlable; updates take time to propagate.

Try it

Disclosure, plainly stated: I built this tool — ToolkitLoop's free favicon generator — because I was tired of the upload-an-account-watermark loop. Everything renders locally in your browser; nothing you type ever leaves the tab.

Sixty seconds, five steps, one download. And now a question for the comments: what's the worst favicon crime you've seen in a browser tab? A stretched logo? A white square on a dark tab? A 404 where the icon should be? I'm collecting specimens for the next iteration — show me your smudges. 👇

I Built a Zero-Backend Markdown Previewer in 40 Lines of JS

bowen Tse — Sat, 17 Oct 2026 03:05:44 +0000

Every Markdown previewer I tried wanted something from me first. An upload. A signup. A desktop app install for what is, at its core, a text transformation.

So I built one that asks for nothing: paste Markdown, get a preview, upload zero bytes. It's one of the 30 free browser tools in my ToolkitLoop collection — full disclosure, it's my own project.

The interesting part wasn't the UI. It was the three problems hiding inside "just render some Markdown."

Problem 1: GFM tables will humble you

CommonMark is the easy part — headings, emphasis, lists. The pain starts with GitHub Flavored Markdown, specifically tables and task lists.

A table looks simple until you hit the edge cases: rows with mismatched cell counts, escaped pipes inside cells (\|), alignment rows with colons. A naive regex-based parser falls apart here. I checked — writing a correct table parser by hand is a weekend of suffering I didn't need.

The pragmatic answer is marked. It's a real, maintained parser with proper GFM support:

import { marked } from 'marked';

const input = document.getElementById('source');
const output = document.getElementById('preview');

function render() {
  const html = marked.parse(input.value, {
    gfm: true,
    breaks: false
  });
  output.innerHTML = html;
}

Forty lines was aspirational; the honest count is a bit more once you add the rest. But the parsing itself is genuinely a few lines, because marked does the heavy lifting — tokenizing, handling the table edge cases, nested lists, all of it.

The lesson: don't hand-roll a Markdown parser in 2026. The spec edge cases are a tar pit. Use a real parser and spend your energy on the problems around it.

Problem 2: Markdown becomes HTML, and HTML bites

Here's the one people skip: marked.parse() returns HTML, and you inject it with innerHTML. That means your previewer is an XSS delivery mechanism unless you sanitize.

Markdown has plenty of HTML smuggling routes. A link like [click](javascript:alert(1)). An image with an onerror attribute in inline HTML. Markdown explicitly allows raw HTML passthrough, which is great for docs and terrible for a preview pane.

The fix is DOMPurify, applied to every render with no exceptions:

import DOMPurify from 'dompurify';

function render() {
  const dirty = marked.parse(input.value, { gfm: true });
  output.innerHTML = DOMPurify.sanitize(dirty);
}

This isn't optional hardening — it's the difference between a tool and a vulnerability. Any time you render user-supplied Markdown as HTML, sanitize the output. Every time. There is no "it's just a preview" exemption; the preview runs in the user's browser with the user's session.

One subtlety worth knowing: sanitizing is about the HTML output, not the Markdown input. Trying to blacklist "dangerous Markdown" is a losing game — the attack surface is the DOM, so that's where you defend.

Problem 3: Big documents turn keystrokes into slideshows

Re-rendering on every keystroke feels instant on a 50-line README. Paste a 10,000-line changelog and the same approach turns typing into a slideshow — parse, sanitize, and re-layout on each keypress is genuinely expensive.

The fix is a debounce, and it's the highest value-to-effort ratio in the whole project:

let timer;

input.addEventListener('input', () => {
  clearTimeout(timer);
  timer = setTimeout(render, 150);
});

150 milliseconds is the sweet spot I landed on: short enough that the preview still feels live, long enough that fast typing coalesces into a single render. For truly huge documents you could get fancier — incremental rendering, virtualized output — but debounce plus a fast parser covers everything I've thrown at it.

Bonus: warn before you load remote images

One more real-world gotcha: Markdown documents love remote images — ![logo](https://cdn.example.com/logo.png). Rendering them means the reader's browser phones home to that server. For a preview tool, silently triggering those requests is rude at best.

I added a lightweight pre-render scan that collects remote image URLs and surfaces them as a warning instead of loading them blindly:

function findRemoteImages(markdown) {
  const urls = [];
  const re = /!\[[^\]]*\]\((https?:[^)\s]+)\)/g;
  let m;
  while ((m = re.exec(markdown))) urls.push(m[1]);
  return [...new Set(urls)];
}

It's deliberately simple — a regex over the source, not the parsed AST — because it only needs to answer "are there external references?" before anything touches the network. The full tool pairs this with a Remote Asset Guard UI, but even the ten-line version changes the trust story: the preview never makes a network request the user didn't approve.

Small feature, outsized trust payoff. The kind of thing you only add after someone pastes a doc full of tracking pixels.

What shipped

The result is Markdown Viewer: paste or open a .md file, get an instant GFM preview, nothing leaves your browser. Along the way I added a few things the core loop needed — reading stats (words, headings, links, code blocks) as a structural sanity check, a guard that warns when your document references remote images, and a "passport" check that flags app-specific syntax like wiki links which won't survive a move to GitHub.

None of those were in the original forty-line plan. They came from actually using the thing on real documents and hitting real paper cuts.

Your turn

Here's my question for you: what's the weirdest Markdown edge case you've ever hit in the wild? Nested task lists inside blockquotes? A table that renders on GitHub but explodes in your static site generator? I'm collecting them — partly out of curiosity, partly because every one is a potential test case. Drop it in the comments.

I Built a Client-Side JSON Fixer That Repairs AI Output

bowen Tse — Fri, 16 Oct 2026 13:34:12 +0000

It started, as these things always do, at 1 AM. I had asked an LLM to generate a chunk of structured data — a few hundred lines of JSON for a seed script — and it came back looking perfect. I pasted it into my project, hit run, and Node handed me this:

Unexpected token } in JSON at position 812

Position 812. Thanks, Node. That narrowed it down to... somewhere in the file.

The real pain: AI output that looks like JSON

If you've worked with LLMs for more than a week, you know this ritual. The output looks pristine in the chat window, but it's a minefield. In my experience, broken AI-generated JSON fails for one of five reasons:

Markdown code fences — the model wraps everything in triple backticks. Those fences are not JSON.
Trailing commas — { "id": 1, }. The model learned JavaScript's looser habits.
Unquoted keys — { id: 1 } works in JS, dies in JSON.parse.
Smart quotes — some chat UIs turn " into “ and ”. Invisible until it breaks.
Comments — models love adding // like this to "helpful" config output. JSON doesn't allow them.

Here's a typical specimen — spot the three violations before you scroll on:

{
  "model": "seed-generator-v3",
  "items": [
    { "id": 1, "name": "Ada", },
    { id: 2, "name": "Grace" },
  ],
  // generated 2026-10-15
}

(Answer: trailing commas after "Ada", and },, the unquoted key id, and the // comment.)

Each one is a five-second fix. Finding it among 500 lines is the part that takes an hour.

Why the usual fixes are annoying

The obvious move is JSON.parse in a scratch file and reading the error message. But native error messages are famously unhelpful — a position number with no context, or in some engines no position at all. Online validators are the next stop, and here's where I got picky: most of them send your paste to a server. When your JSON contains a staging API key or a chunk of real user data, that's a hard no for me.

The third option — hand-rolling a fixer script — is what I actually did for a while. Here's the tiny trick that made JSON.parse errors bearable:

function pinpointError(raw) {
  try {
    JSON.parse(raw);
    return null; // valid!
  } catch (err) {
    const m = /position (\d+)/.exec(err.message);
    const pos = m ? Number(m[1]) : 0;
    // show 60 chars of context around the failure point
    return raw.slice(Math.max(0, pos - 40), pos + 20);
  }
}

This one snippet turned "position 812" into the actual offending character with context. Game changer. But I still had to strip code fences by hand, regex trailing commas myself, and — the sketchy part — I once "fixed" a payload by running a regex that ate a comma inside a string value. That was the moment I decided repair tools need a preview before apply step, or they're just a fancier way to corrupt data.

So I built the tool I kept wishing existed

Full disclosure: I built this tool — it's a browser-local JSON syntax validator and debugging workspace. Everything I'm about to describe, I use myself whenever an API or an LLM hands me suspect JSON. Here's what the workflow looks like:

1. Paste and validate. No account, no upload. Paste in the tool and it checks syntax immediately, entirely inside your browser tab. You can verify the "no upload" claim by opening the Network panel — nothing leaves the page.

2. Read a location-aware error message. Instead of a bare position number, you get the line, the column, and the surrounding context. Plus two things plain validators skip: duplicate-key warnings (technically valid JSON, but parsers silently keep only the last value — a silent data-loss bug) and interoperability notes that flag constructs which parse in one language but behave differently in another.

3. Use the safe repair preview. This is the part I care about most. The preview handles the common copy-and-paste fixes — code fences, trailing commas, quote normalization, unquoted keys — and shows you the resulting document before anything is applied. The fixes stay in the preview until you explicitly choose to use them. No regex roulette on your own data.

4. Validate against a schema, still locally. If you're generating fixtures for an API, you can paste an inline JSON Schema and validate against it in the same tab. Remote $ref values are never fetched, so there's no network round-trip and no leaking your schema.

The whole flow — paste, locate, preview-repair, schema-check — takes about three minutes for the typical "the model gave me 400 lines and one comma is wrong" case. You can try it here: JSON Validator Online.

The takeaway

AI models will keep emitting almost-JSON for the foreseeable future — they generate tokens, not grammars, so trailing commas and code fences are features of how they write, not bugs in your prompt. The fix isn't better prompting; it's a repair workflow that assumes the input is hostile: validate locally, see the exact error location, preview every repair before applying it, and never upload data you wouldn't email to a stranger.

What's the weirdest broken-JSON-from-AI story you've hit? The fence-in-a-fence? A smart quote hiding in a 2,000-line file? Drop it in the comments — I want to know I'm not alone in this.

I Built a Zero-Backend Percentage Calculator: 5 Lessons

bowen Tse — Tue, 13 Oct 2026 03:20:24 +0000

Every developer does percentage math daily — discount logic, progress bars, test coverage, "what share of users converted." And most of us reach for a calculator app or a quick node -e one-liner without thinking twice about it.

But percentages have sharp edges, especially in JavaScript. This post collects the five percentage tricks I actually use, with the code to match, and the lessons from shipping a free percentage calculator that runs entirely in the browser — zero backend, zero signup. (Disclosure: I built it — it's one of 30 browser-based tools I maintain.)

Trick 1: `x * pct / 100` — and know why the order matters

The naive version:

const percentOf = (pct, value) => (value * pct) / 100;

percentOf(15, 80); // 12

Multiply first, divide last. This isn't just style — doing (value / 100) * pct introduces a rounding step earlier in the pipeline. Keep integers whole as long as you can.

The reverse is equally common in UI code ("user typed a tip amount, what percent is that?"):

const whatPercent = (part, whole) => (part / whole) * 100;

whatPercent(12, 80); // 15

Trick 2: the flip — `a% of b === b% of a`

This mental-math trick works in code too, as an optimization for readability: whenever one side is rounder, compute from that side. And it makes a great unit test:

const percentOf = (pct, value) => (value * pct) / 100;

// 18% of 50 === 50% of 18 === 9
console.assert(percentOf(18, 50) === percentOf(50, 18));

If your percent function ever fails that symmetry assertion, something is wrong with your rounding, not your math.

Trick 3: the mental-math hacks, ported to code

The tricks that make percentages fast in your head also make good, readable utility functions. The classic "10% + 5% + 1% building blocks" method:

const tenPct = (v) => v / 10;
const fivePct = (v) => v / 20;
const onePct = (v) => v / 100;

// 17% of 240 = 10% + 5% + 1% + 1%
const seventeenPctOf240 =
  tenPct(240) + fivePct(240) + onePct(240) + onePct(240); // 40.8

Nobody writes production code this way — 240 * 0.17 is shorter — but it's the same decomposition a good explainability UI uses when it shows its work ("10% = 24, 5% = 12, …"). If your product ever needs to show a calculation step by step (finance, education, checkout breakdowns), decompose from round blocks instead of dumping one magic multiplication.

Quarter shortcuts map to bit-shifts in the integer domain:

const quarterOf = (cents) => cents >> 2; // exact for integers
quarterOf(9600); // 2400 cents = $24.00, exactly 25% of $96

No float involved, no rounding error possible. When your domain is money, staying in integers isn't a micro-optimization — it's the whole correctness strategy.

Trick 4: never trust floats — the 2.9985000000000004 problem

Here's the one that bites in production. A 15% tip on a $19.99 bill:

19.99 * 0.15; // 2.9985000000000004  — not 2.9985!

IEEE 754 doubles can't represent 0.15 or 19.99 exactly, and percentage math multiplies those tiny errors into visible ones. Classic demos: 0.1 + 0.2 gives 0.30000000000000004. In a finance-adjacent UI, that trailing 00000000004 is a trust killer.

Three fixes, from weakest to strongest:

Fix A — toFixed at the boundary. Fine for display, but it returns a string and hides the error rather than removing it:

(19.99 * 0.15).toFixed(2); // "3.00"

Fix B — integer cents. Do all math in the smallest unit, divide only when rendering:

const cents = Math.round(19.99 * 100);      // 1999
const tipCents = Math.round((cents * 15) / 100); // 300
tipCents / 100;                              // 3.00 — exact

Fix C — a decimal-round helper for the general case:

const roundTo = (n, decimals) =>
  Math.round((n + Number.EPSILON) * 10 ** decimals) / 10 ** decimals;

roundTo(19.99 * 0.15, 2); // 3

The Number.EPSILON nudge handles the cases where the float lands just below a .5 boundary. For the calculator I shipped, money paths use integer cents (Fix B) and general math uses the EPSILON helper (Fix C) — belt and suspenders.

Trick 5: percentage change without the sign bug

const percentChange = (oldVal, newVal) =>
  ((newVal - oldVal) / oldVal) * 100;

percentChange(40, 50); // 25
percentChange(60, 45); // -25

Two gotchas I've seen in real codebases: dividing by newVal instead of oldVal (changes the baseline), and forgetting that a "200% increase" means tripled, not doubled. If you're rendering "+200%" in a dashboard, make sure your users read it the same way you wrote it.

Shipping it: lessons from zero-backend

The percentage calculator at toolkitloop.com/percentage-calculator is pure client-side HTML/CSS/JS. No API, no database, no analytics beacon phoning home with your numbers. Lessons from that architecture:

Validation is the whole backend. Every input is a string until you prove otherwise — parseFloat on empty input, comma decimals, pasted currency symbols. A calculator's input parser handles more cases than its math engine:

const parseAmount = (raw) => {
  const cleaned = raw.replace(/[^0-9.,-]/g, "").replace(",", ".");
  const n = parseFloat(cleaned);
  return Number.isFinite(n) ? n : null; // null → show "enter a number"
};

Careful with the naive version above: on "$1,299.99" it produces "1.299.99", which parseFloat truncates to 1.299. Real-world parsing has to decide whether a comma is a thousands separator or a decimal mark before stripping it — usually by checking which of , or . appears last. This is the unglamorous 80% of a "simple" tool: not the arithmetic, but the twenty ways humans type a number.

State lives in the URL. ?pct=15&value=80 makes results shareable and bookmarkable — a poor man's API.
Edge cases ARE the product. Division by zero, negative percentages, >100% — a calculator that crashes on 0 is worse than no calculator.

Try it and tell me your worst float bug

Percent math is simple until floats get involved — then it's a rite of passage. What's the worst floating-point bug you've shipped or caught? 0.1 + 0.2 stories especially welcome in the comments.

And if you need exact percentage answers without reaching for node -e every time, the free calculator is at toolkitloop.com/percentage-calculator — no signup, your numbers never leave your browser.

Character Counting Is Harder Than It Looks: A Dev's Guide

bowen Tse — Sun, 11 Oct 2026 04:24:55 +0000

Every developer has written something like if (text.length > 280). And every developer with users who type emoji has watched that check break in production. Counting characters is one of those problems that looks trivial until a platform, an encoding, or a family emoji proves otherwise.

Here is a field guide to the three counting regimes you will actually meet — and the code that handles each.

Regime 1: graphemes — what the reader sees

A string is not a sequence of characters. It is a sequence of UTF-16 code units, and one visible character can be many of them:

"👨‍👩‍👧‍👦".length; // 11 — but your eyes see ONE character
"é".length;        // 2 if built from e + combining accent

The fix is the grapheme cluster — what a reader perceives as a single character — and the browser already has an API for it:

const segmenter = new Intl.Segmenter("en", { granularity: "grapheme" });
const count = [...segmenter.segment("👨‍👩‍👧‍👦")].length; // 1

If you build any "max N characters" validation, count segments, not .length. Your users' emoji will thank you. (One caveat: Intl.Segmenter support is broad in modern browsers but check your target — Node 16+ and all evergreen browsers have it.)

Regime 2: X's weighted counting — URLs cost 23, always

A standard X post allows 280 weighted characters. The weighting rules (in the open-source twitter-text config) mean:

Every URL counts as 23 characters, no matter its real length — X wraps links in its own shortener.
Some ranges (emoji included) weigh more than 1.

So this announcement — 193 characters as your eyes count them — is only about 169 weighted: the 47-character URL collapses to 23 while the rocket counts double.

// sketch of the idea, not the full config
function weightedLength(text) {
  const urlRegex = /https?:\/\/\S+/g;
  const withoutUrls = text.replace(urlRegex, "");
  const urls = (text.match(urlRegex) || []).length;
  // emoji & wide ranges weigh 2 (simplified)
  const body = [...withoutUrls].reduce(
    (n, ch) => n + (/\p{Extended_Pictographic}/u.test(ch) ? 2 : 1), 0);
  return body + urls * 23;
}

Moral: never validate against X's limit with a plain character count. Use the platform's rule — or a tool that applies it for you.

Regime 3: SMS segments — the encoding tax

SMS is counted in segments, and the segment size depends on encoding:

Encoding	Single message	Concatenated segments
GSM-7 (plain Latin)	160 chars	153 chars each
UCS-2 (emoji/CJK)	70 chars	67 chars each

One emoji flips the entire message to UCS-2. Even € costs two GSM-7 units. A 165-character marketing text with one emoji can silently become three billable segments instead of two. If you build anything that sends SMS, surface the segment count before the user hits send.

The tool I built for all three

Disclosure first: I built toolkitloop.com/character-counter — one of 30 free browser tools I maintain. It counts visible graphemes (family emoji = 1), has an X mode that applies the weighted URL rule, shows with/without-spaces totals, and runs 100% client-side — no signup, nothing uploaded. Handy as a pre-publish check before the platform's own composer.

Your turn

What is the worst character-counting bug you have shipped or seen? The emoji-that-ate-the-limit? The SMS bill surprise? Drop it in the comments — I am collecting edge cases to make the tool smarter.

I Built a Client-Side Decision Wheel: The Randomness Bit

bowen Tse — Fri, 09 Oct 2026 02:55:44 +0000

Group decisions are where friendships go to stall. "Where do we eat?" "Who goes first?" "Who does the dishes?" — everyone has a preference, nobody wants to be the decider. So I built a small spinning wheel that takes the call: type a question, spin, get YES or NO. Three seconds, zero arguments.

The spin animation is the fun part. The interesting part — the part that actually matters if anyone's running a giveaway — is how the wheel picks.

Disclosure: I built this tool at toolkitloop.com/yes-no-wheel. It's one of 30 free client-side tools I maintain. The code patterns below are general; steal them.

The naive version everyone writes

The first implementation of any wheel looks like this:

const segments = ["YES", "NO"];
function spin() {
  return segments[Math.floor(Math.random() * segments.length)];
}

Math.random() is fine for picking lunch. But it has two properties that should make you pause before using it for anything people care about:

It's not cryptographically secure. The sequence is deterministic given the internal state. Nobody's going to reverse-engineer your lunch wheel, but "provably fair" giveaway draws deserve better.
Modulo bias. Math.floor(Math.random() * n) is almost uniform, but with certain ranges the distribution isn't perfectly even. For a 2-segment wheel the effect is negligible; for a 47-entrant giveaway wheel, tiny biases are exactly the kind of thing a sore loser will (correctly) point at.

The fair version: crypto.getRandomValues + rejection sampling

The Web Crypto API gives us real entropy from the OS. The trick is converting random bytes into a uniform index without modulo bias — that's what rejection sampling does:

// Unbiased random index in [0, n) using Web Crypto
function fairIndex(n) {
  const max = 0xffffffff;
  // Largest multiple of n that fits in 32 bits — reject anything above it
  const limit = max - (max % n);
  const buf = new Uint32Array(1);
  let x;
  do {
    crypto.getRandomValues(buf);
    x = buf[0];
  } while (x >= limit);
  return x % n;
}

function spinWheel(segments) {
  return segments[fairIndex(segments.length)];
}

The loop rejects the leftover range that would make some indices slightly more likely, then maps the remainder uniformly. The expected number of iterations is barely above 1 — the do...while almost never repeats. This is a ~15-line function, runs entirely client-side, and gives you a draw you can defend.

Separating selection from animation

One design decision that made the code much cleaner: the animation is theater; the selection is math. The wheel's final resting angle is computed from the already-chosen index, and the spin animation just plays out to that angle:

// Selection happens first; animation follows
const winnerIndex = fairIndex(segments.length);
const sliceAngle = 360 / segments.length;
// Land the pointer in the middle of the winning slice,
// after a few full rotations for drama
const finalAngle = 360 * 5 + (winnerIndex * sliceAngle) + sliceAngle / 2;
wheel.style.transform = `rotate(${finalAngle}deg)`;

This separation has a nice side effect: you can unit-test fairness (run 100k spins, check the distribution) without touching any animation code. If you're building any kind of picker, test the distribution — chi-square is overkill, but eyeballing a histogram of 10k draws catches real bugs.

Everything stays on the device

The whole thing — entropy, selection, rendering — happens in the browser. No server round-trip, no list of entrant names uploaded anywhere. For a giveaway tool this isn't just a nice privacy story; it removes an entire class of "what did you do with my email list?" questions.

Try it / take it apart

The tool is free and needs no account: toolkitloop.com/yes-no-wheel — yes/no mode for quick calls, custom segments for name wheels and giveaways.

Question for the comments: have you ever caught Math.random()-style bias causing a real problem — a lopsided A/B test, a "random" shuffle that wasn't, a giveaway dispute? I'd love to hear the war stories. 👇

How to Scan QR Codes from Screenshots Without an App

bowen Tse — Wed, 07 Oct 2026 12:23:13 +0000

Every developer has lived this one. A QR code shows up on your own screen — a 2FA setup code in a desktop app, a Wi-Fi password in a chat message, a ticket in an email — and your phone's camera is suddenly useless. You can't photograph your own display without a second device and a lot of glare.

The usual workarounds are all bad: save the image, email it to yourself, scan it with your phone. Or my personal low point: taking a photo of my monitor with my phone and squinting at the result.

There's a much better way, and it runs entirely in the browser.

The trick: your clipboard is an input device

Modern browsers let a web page read an image straight from your clipboard. So the whole workflow is:

Screenshot the code however you normally do (Win+Shift+S, Cmd+Shift+4, phone screenshot button). Don't bother saving — it's in your clipboard.
Open this free QR scanner.
Click the page, press Ctrl+V (Cmd+V on Mac).
Read the decoded result: full link or text, code format, and a link-safety preview.

Five seconds, no install, no account. The same page also handles file uploads (for saved screenshots) and camera scans (for printed codes), and it reads QR, UPC, and common 1D/2D formats without asking you to pick a mode.

(Disclosure: I built this tool. It's one of 30 free browser-based utilities I'm shipping at ToolkitLoop — everything runs client-side, no backend.)

What's actually happening under the hood

If you're curious how a paste-to-decode flow works, the pipeline is refreshingly simple. Conceptually:

Capture: the page receives the clipboard image as a bitmap.
Rasterize: it draws that bitmap onto a <canvas> so it can read raw pixels via getImageData.
Decode: a decoding library converts the pixel grid into text — finding the QR finder patterns, sampling the module grid, running error correction.
Retry passes: for damaged inputs, the pipeline re-runs on transformed copies — rotated, inverted, scaled — until something decodes.

An illustrative sketch of the shape (not the site's actual source):

// Illustrative pipeline — the general pattern, not production code
async function decodeFromScreenshot(imageBitmap, decode) {
  const canvas = document.createElement("canvas");
  canvas.width = imageBitmap.width;
  canvas.height = imageBitmap.height;
  const ctx = canvas.getContext("2d");
  ctx.drawImage(imageBitmap, 0, 0);
  const pixels = ctx.getImageData(0, 0, canvas.width, canvas.height);

  // Try the straight decode first, then rescue passes
  // (rotation, inversion, deeper analysis) for damaged codes
  for (const transform of [identity, rotate90, invert, upscale]) {
    const result = decode(transform(pixels));
    if (result) return result;
  }
  return null;
}

The interesting bit is that all of this happens on your device. Screenshots frequently contain sensitive stuff — chat threads, tickets, payment screens — so a scanner that uploads your image to a server is a privacy smell. Client-side decoding means the pixels never leave the browser tab. Camera permission, likewise, is only requested when you explicitly choose camera mode.

Rescue Mode: for the ugly screenshots

Real-world screenshots are hostile inputs: dark-mode inverted colors, notification banners overlapping the code, tiny codes in a corner of a 4K screenshot. The scanner's Rescue Mode retries locally with rotation, inversion, and deeper analysis passes.

Practical tips when a scan fails:

Crop tight around the code before scanning — less noise, better decode rate.
Dark mode screenshots invert the colors; an inversion retry pass handles this automatically.
Enlarge small codes — zoom the image and re-screenshot rather than scanning a 40px thumbnail.
Make sure all three QR finder squares are visible; a clipped code can't decode no matter what.

The security habit worth building

A decoder can show you the destination, but it can't decide for you. QR codes are a classic phishing vector — a sticker over a restaurant's real code can point at a lookalike login page. The preview-first flow exists so you can check the actual domain before opening anything, especially for codes that arrived as screenshots where visual context is easy to fake.

Always read the decoded URL before tapping through. It's a two-second habit that kills an entire class of attacks.

Try it

Next time a QR code lands on your own screen: screenshot, Ctrl+V, done. The scanner is free, no signup, at toolkitloop.com/qr-code-scanner.

What's the most awkward "QR code on my own screen" situation you've hit — and how did you solve it before you knew the paste trick? Curious what workflows people have invented for this.

How to Convert Decimals to Fractions: 3 Steps With Examples

bowen Tse — Mon, 05 Oct 2026 03:00:30 +0000

Your API returns 0.375. The design mock says "⅜". The recipe your app is scaling says 0.666 cups but the user owns measuring cups marked in quarters. Somewhere between the machine world and the human world, decimals have to become fractions — and every developer, designer, or DIYer hits this gap eventually.

The good news: the conversion is a 3-step mechanical process. No memorization, no algebra tricks. Here's the whole thing.

The method in 30 seconds

Write the decimal over its place value. One decimal place → over 10. Two → over 100. Three → over 1000.
Find the greatest common divisor of the top and bottom numbers.
Divide both by the GCD. That's your simplified fraction.

That's it. 0.75 → 75/100 → GCD(75, 100) = 25 → 3/4. Everything below is just this pattern applied to different numbers.

Why the place-value trick works

A decimal is already a fraction in disguise. "0.75" literally means "75 hundredths" — the digits after the point tell you the denominator directly. You're not computing anything in step 1; you're just rewriting notation.

The only real math is step 3: simplification. And even that has a boringly reliable procedure — divide both numbers by 2, 3, 5, whatever divides them evenly, until nothing divides both. What survives is the GCD.

Worked examples (the ones you'll actually look up)

0.5 → 5/10 → GCD(5,10) = 5 → 1/2

0.75 → 75/100 → GCD(75,100) = 25 → 3/4

0.125 → 125/1000 → GCD(125,1000) = 125 → 1/8

0.6 → 6/10 → GCD(6,10) = 2 → 3/5

1.25 → separate the whole number: 1 + 0.25 → 25/100 → GCD(25,100) = 25 → 1 1/4

Notice the pattern: the denominator is always 10, 100, or 1000 at first, then it collapses. If you remember only one thing, remember this: count the decimal places, that's your zeros.

The one case that breaks the pattern

Repeating decimals — 0.333…, 0.1666… — never terminate, so they can't be written over a power of 10. 0.333… = 1/3, but getting there needs a different technique (multiply by 10, subtract, solve). In practice, this is exactly where you stop doing it by hand and use a tool.

A 10-second demo: the tool I built (disclosure: it's mine)

Full disclosure: I built this. It's one of 30 free utilities on ToolkitLoop, and it's 100% client-side — your numbers never leave the browser.

Type a decimal and you get the simplified fraction instantly, with each simplification step shown so you can verify the math instead of trusting a black box:

It also handles the awkward cases — repeating decimals, mixed numbers like 1.25, and longer decimals where the GCD isn't obvious:

Try it here: decimal to fraction converter

The cheat sheet worth bookmarking

These ten cover nearly every real-world lookup — recipes, tape measures, CSS values, grades:

Decimal	Fraction
0.125	1/8
0.2	1/5
0.25	1/4
0.333…	1/3
0.375	3/8
0.5	1/2
0.625	5/8
0.666…	2/3
0.75	3/4
0.875	7/8

If you're building anything that displays measurements to humans — a recipe scaler, a dashboard, a CNC readout — keep this table one keystroke away.

Bonus: the same method in 8 lines of JavaScript

Since this is dev.to, here's the whole 3-step method as code — place value, GCD via Euclid's algorithm, simplify:

function gcd(a, b) { return b ? gcd(b, a % b) : a; }

function decimalToFraction(d) {
  const places = (d.toString().split('.')[1] || '').length;
  const denom = 10 ** places;          // step 1: place value
  const num = Math.round(d * denom);
  const g = gcd(num, denom);           // step 2: GCD
  return `${num / g}/${denom / g}`;    // step 3: simplify
}

decimalToFraction(0.75);  // "3/4"
decimalToFraction(0.125); // "1/8"

Caveat: this handles terminating decimals only — same as the manual method. Repeating decimals and floating-point dust (looking at you, 0.1 + 0.2) need a tolerance-based approach, which is exactly why the browser tool linked above exists: it shows the steps so you're never debugging a black box.

The takeaway

Decimals come from machines. Fractions come from humans. Converting is a 3-step translation: place value, GCD, simplify. For one-off conversions, do it by hand; for real work, bookmark the tool.

What's the weirdest decimal-to-fraction conversion you've had to do in a project? I'm curious where this actually shows up outside school math — drop it in the comments.

DEV Community: bowen Tse

I Built 30 Free Tools That Run Entirely in Your Browser

I Built 30 Free Tools That Run Entirely in Your Browser

The upload button that broke me

The insight: your browser is a supercomputer

Building it: browser-first as architecture, not marketing

A concrete example: the image converter pipeline

Thirty tools, one philosophy

The distribution problem (being honest)

Why free is sustainable (the math)

What's next

Try it, break it, tell me

I Built a Client-Side JSON Formatter: 5 Lessons for Devs

1. JSON is stricter than JavaScript, and that is the point

2. Safe repair means a small, honest list

3. Readability is a debugging tool, not cosmetics

4. Never upload data you would not paste into a chat

5. Syntax is not schema, and confusing them wastes hours

Putting it together

I Built a Zero-Backend M3U8 Player: 5 HLS Lessons for Devs

1. M3U8 is not a video format — it's a shopping list

2. Your browser already knows how to play the video — it just can't read the menu

3. CORS is the #1 reason "it works in VLC but not in my browser"

4. A manifest inspector is worth more than a play button

5. Zero backend is a feature, not just a cost saving

Takeaways

Compress Any Image to Exactly 100KB: A Binary-Search Trick

Why the quality slider is the wrong primitive

Think target-first

Don't want to write code? I built this for you

The real question

I Built a Client-Side Favicon Generator (60-Second Tutorial)

The 60-second workflow

The canvas technique: legible glyphs at every size

ICO vs PNG vs SVG, in 30 seconds

Two gotchas before you ship

Try it

I Built a Zero-Backend Markdown Previewer in 40 Lines of JS

Problem 1: GFM tables will humble you

Problem 2: Markdown becomes HTML, and HTML bites

Problem 3: Big documents turn keystrokes into slideshows

Bonus: warn before you load remote images

What shipped

Your turn

I Built a Client-Side JSON Fixer That Repairs AI Output

The real pain: AI output that looks like JSON

Why the usual fixes are annoying

So I built the tool I kept wishing existed

The takeaway

I Built a Zero-Backend Percentage Calculator: 5 Lessons

Trick 1: x * pct / 100 — and know why the order matters

Trick 2: the flip — a% of b === b% of a

Trick 3: the mental-math hacks, ported to code

Trick 4: never trust floats — the 2.9985000000000004 problem

Trick 5: percentage change without the sign bug

Shipping it: lessons from zero-backend

Try it and tell me your worst float bug

Character Counting Is Harder Than It Looks: A Dev's Guide

Regime 1: graphemes — what the reader sees

Regime 2: X's weighted counting — URLs cost 23, always

Regime 3: SMS segments — the encoding tax

The tool I built for all three

Your turn

I Built a Client-Side Decision Wheel: The Randomness Bit

The naive version everyone writes

The fair version: crypto.getRandomValues + rejection sampling

Separating selection from animation

Everything stays on the device

Try it / take it apart

How to Scan QR Codes from Screenshots Without an App

The trick: your clipboard is an input device

What's actually happening under the hood

Rescue Mode: for the ugly screenshots

The security habit worth building

Try it

How to Convert Decimals to Fractions: 3 Steps With Examples

The method in 30 seconds

Why the place-value trick works

Worked examples (the ones you'll actually look up)

The one case that breaks the pattern

Trick 1: `x * pct / 100` — and know why the order matters

Trick 2: the flip — `a% of b === b% of a`