DEV Community: bowen Tse

I Built a Batch Image Resizer That Never Uploads a Photo

bowen Tse — Sat, 31 Oct 2026 09:47:26 +0000

I built a batch image resizer that never uploads a photo. Here is the part I did not expect to be interesting: the resize itself is ten lines of canvas code, and almost every bad result comes from the geometry around those ten lines, not from the drawing call.

Disclosure up front: I built this tool — the free image resizer at https://toolkitloop.com/image-resizer. It resizes up to 10 images in the browser, in exact pixels or by percentage, with Fit, Crop or Pad modes, and downloads the batch as a ZIP. This post is about the decisions inside it, because they are the same decisions you will hit in any image pipeline you build.

The annoying version of this problem

The usual flow for resizing an image is: upload to a server, wait, download the result, repeat for the next nine images. For a single thumbnail that is tolerable. For a batch — ten product photos, a folder of screenshots — it is a slow, leaky loop, and every upload is a copy of your file living somewhere you do not control.

The browser already has everything needed to do this locally: createImageBitmap decodes the file, <canvas> draws it at a new size, and toBlob hands back the result. No server, no queue, no upload. The interesting work is deciding what rectangle to draw.

Fit, crop, pad: three rectangles, three promises

Given a source image of sw × sh and a target of tw × th, the scale factor for Fit is the smaller of the two ratios; for Crop it is the larger. That one-line difference is the whole feature:

function fitRect(sw, sh, tw, th, mode) {
  const scale = mode === 'crop'
    ? Math.max(tw / sw, th / sh)
    : Math.min(tw / sw, th / sh);
  const dw = sw * scale;
  const dh = sh * scale;
  // Fit: center the smaller rect, leaving empty space.
  // Crop: center the larger rect, letting edges overflow.
  // Pad: same as Fit, then fill the canvas background first.
  return { dx: (tw - dw) / 2, dy: (th - dh) / 2, dw, dh };
}

Fit promises "nothing is cut off" and pays for it with empty space. Crop promises "the box is exactly full" and pays for it with trimmed edges. Pad is Fit plus a background fill, so the box is full and nothing is cut. If you have ever wondered why two resizers disagree on the same input, it is almost always because they silently chose different promises. Making the choice explicit — and previewing it — removes a whole class of bug reports.

The draw itself is unremarkable, and that is the point:

async function resizeImage(file, tw, th, mode) {
  const bitmap = await createImageBitmap(file);
  const canvas = new OffscreenCanvas(tw, th);
  const ctx = canvas.getContext('2d');
  const { dx, dy, dw, dh } = fitRect(bitmap.width, bitmap.height, tw, th, mode);
  ctx.drawImage(bitmap, dx, dy, dw, dh);
  const blob = await canvas.convertToBlob({ type: 'image/png' });
  bitmap.close();
  return blob;
}

Two details worth keeping. First, bitmap.close() matters in a batch loop: ten decoded images held open at once will eat memory you could have freed. Second, the output format is a decision, not a default. Re-encoding a JPEG as PNG can balloon the file; re-encoding a PNG with transparency as JPEG destroys the transparency. Keep the output format close to the input unless you have a reason to change it.

The batch problem is not the loop

Resizing ten images is a loop over the function above. The batch problem is everything around the loop: progress reporting per file, one failure that should not kill the other nine, and a single download at the end instead of ten save dialogs. A ZIP download at the end is what makes batch feel like batch; without it you have just done the same single-image job ten times.

There is also a quiet privacy consequence worth naming. When resizing happens locally, the tool never sees the image at all — no filenames, no contents, no metadata sent to analytics. Resized exports are created without original metadata where the browser pipeline supports it. That is not a marketing line; it is what falls out of never uploading in the first place.

Upscaling: the honest limitation

Every resizer has one limitation it should admit: enlarging cannot create detail. A 200-pixel icon stretched to 1200 pixels will look soft in every implementation, because the information was never there. The honest behaviour is to let the user do it, show the preview, and not pretend an algorithm recovered something. Downscaling is forgiving; upscaling is where previews earn their keep.

Three lessons I would keep for the next image tool

Name the geometry promise. Fit, Crop and Pad are not cosmetic options; they are different contracts with the user. Silent defaults here are bugs.
Preview before download, especially for crops. A crop that cuts a face is obvious at preview size and expensive after re-upload.
Batch is a UX feature, not a loop. Per-file progress, isolated failures, and one ZIP download are what make ten images feel different from one image ten times.

If you have built an image pipeline, which failure mode bit you first — the geometry, the format re-encode, or the batch download? I keep finding new edge cases in the crop preview, so I am curious where yours live.

Try the tool this came from: https://toolkitloop.com/image-resizer

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

bowen Tse — Thu, 29 Oct 2026 02:58:56 +0000

Every developer has written the naive version at least once:

const words = text.trim().split(/\s+/).length;

It works on a clean paragraph. Then a user pastes an essay and the number is wrong, and the bug report says your counter disagrees with Word, with Google Docs, and with itself on different browsers. The disagreement is not a rounding error. It is a segmentation problem, and once you see the rules, the naive version looks brave rather than correct.

Disclosure first: I built a free browser word counter at https://toolkitloop.com/word-counter, and this post explains the segmentation behaviour its own page documents. The tool counts entirely in the browser — nothing is uploaded — which is the right architecture for a counter, because pasting an unpublished essay into a server is a privacy ask nobody should have to make.

The naive split fails in specific, predictable places

Splitting on whitespace assumes every word is separated by a space. Real text breaks that assumption in at least five ways, and the ToolkitLoop tool page lists them as worked examples:

don't is 1 word. An apostrophe stays inside a word.
well-known is 1 word. A hyphenated compound stays together.
hello—world is 2 words. An em dash separates words.
3.14 is 1 word. A decimal number counts as one word.
An emoji is 0 words, but it is still a character.

A whitespace split gets don't and well-known right by accident, gets hello—world wrong (it sees one token), gets 3.14 right by accident, and counts emoji as words, which users find plainly wrong. Worse, it fails completely on text that does not use spaces between words at all. Mixed text such as Chinese and English is segmented without relying on spaces alone, and a regex split has no answer for where one Chinese word ends and the next begins.

The browser already has a segmenter: use it

Modern browsers expose Intl.Segmenter, a language-aware segmentation API built for exactly this job. A word counter built on it looks like this:

function countWords(text) {
  if (!("Segmenter" in Intl)) {
    // Fallback for older browsers: whitespace split, documented as approximate.
    return text.trim() ? text.trim().split(/\s+/).length : 0;
  }
  const segmenter = new Intl.Segmenter(undefined, { granularity: "word" });
  let count = 0;
  for (const { segment, isWordLike } of segmenter.segment(text)) {
    if (isWordLike) count++;
  }
  return count;
}

Two details matter here. First, isWordLike is the filter that keeps emoji out of the word count while leaving them in the character count — the exact behaviour users expect. Second, the locale argument: passing undefined lets the browser use its default locale, which is a reasonable default for a general-purpose tool, but a counter aimed at one language should pass that locale explicitly and say so. Segmentation is locale-sensitive, and silently using the wrong locale is how you get a counter that is confident and wrong.

Character counts deserve the same care. Counting characters with text.length counts UTF-16 code units, not what a user sees. An emoji outside the basic multilingual plane is two code units, and a flag or family emoji is several. If your UI promises a "character count" and a user pastes emoji, length will over-count in a way that is visible and annoying. Intl.Segmenter with granularity: "grapheme" gives you the user-visible units; use it for the character number you display next to the word number.

Sentences, paragraphs and reading time are estimates, not facts

A counter usually shows more than words. Each extra number has its own failure mode, and honest UI copy should reflect that:

Sentences depend on terminator detection. Abbreviations (Dr., e.g.), decimals (3.14) and ellipses all break naive period-splitting. Intl.Segmenter with granularity: "sentence" handles the common cases better than a regex, but no segmenter resolves every abbreviation correctly.
Paragraphs are the most reliable number: split on blank lines and you are usually right, provided you decide whether a single line break is a paragraph break or a soft wrap in the pasted text. Document that choice.
Reading time is an estimate of time, not a measure of quality. It is computed from a words-per-minute assumption that varies by audience and purpose. Present it as "about N min", never as a precise figure.

The ToolkitLoop page states this plainly: reading time estimates how long a reader may spend with the text, not whether the copy is good or complete. That sentence belongs in your UI copy too, because users will otherwise treat the estimate as a grade.

Why counters disagree — and what to tell users

When a user says "Word says 512, your tool says 508", the correct response is not to defend your number. It is to explain that different tools apply different segmentation rules, and that the destination system is the authority for a strict limit. The practical advice that follows is genuinely useful:

Paste the exact version you intend to submit, headings and bullets included, because counters count what you paste.
Edit with your counter as a guardrail, not a judge.
Verify the final text in the system that receives it — the editor, CMS or application portal — before submitting.

That third step is the one most counter UIs forget to say. A counter that claims to be the final authority is lying about a problem it cannot solve, since it cannot know the portal's rules. A counter that says "use the destination's count for a strict rule" is more trustworthy, and trust is the only moat a free tool like this has.

Building it locally is the whole point

There is a reason this kind of tool belongs in the browser with no backend. The input is often unpublished: an essay, a job application, a client draft, a manuscript. Asking a user to upload that text to count its words is a privacy cost with no technical justification — segmentation runs fine on the client. The tool page's promise is simple: counting runs locally in the browser, the text is not sent to a server or analytics service, and a word goal or limit setting stays on the user's own device. If you build a counter, that local-first shape is not a nice-to-have; it is the feature that makes the tool safe to recommend to students and writers.

The same reasoning applies to the rest of the numbers. Characters, sentences, paragraphs and reading time are all derivable on the client. Nothing in this feature needs a server, an account or a database. When a tool's value proposition is "paste your unfinished work here", the architecture is the privacy policy.

The checklist I would ship

Use Intl.Segmenter with granularity: "word" and filter on isWordLike; keep a documented whitespace fallback for older browsers.
Count characters as graphemes, not UTF-16 code units.
Show words, characters, sentences, paragraphs and reading time together, because each answers a different question.
Say plainly that the destination system's count wins for a strict limit.
Keep everything local: no upload, no account, no analytics on the pasted text.
Let users set a word goal or limit that persists on their device.

Try the edge cases in your own counter and tell me which one surprises you most: is it the em dash splitting hello—world, the emoji counting as zero words, or the mixed-language text that breaks a whitespace split entirely? The answer usually tells you which assumption your implementation is still hiding.

Why Dynamic QR Codes Break: A Static-Code Fix for Devs

bowen Tse — Tue, 27 Oct 2026 02:57:11 +0000

Disclosure first, because this is a tool post: I built the QR code generator at ToolkitLoop, and this article explains a failure mode I keep seeing in support threads — a printed QR code that "suddenly expired." It almost never expired. Something behind it died, and you can prove which thing in about a minute.

The mental model most people get wrong

A QR code is not a link. It is a payload, and what the payload contains decides everything about how it can fail.

A static QR code's payload is the content: https://example.com/menu, a Wi-Fi credential block, a vCard. The scanner reads it, and there is nothing else to go wrong except the destination itself.

A dynamic QR code's payload is a pointer: something like https://short.example/abc123. The scanner reads the pointer, the browser asks that short domain where to go, and only then does the visitor reach your page. That extra hop is the whole product — it is what lets you change the destination without reprinting — and it is also a single point of failure you do not own.

So when someone says "my free QR code stopped working," the first question is never "what is wrong with the squares?" It is "was the payload a pointer, and is the pointer still alive?"

A one-minute diagnosis you can actually run

Suppose a printed menu code now lands on an error page. Do not regenerate it yet. Work through this:

Scan it and read the URL the scanner shows before tapping. If it is a short domain you do not control, you are in dynamic-code territory.
Open that URL in a desktop browser and watch the address bar. Does it stay put, bounce through two or three hops, or land on a parking page? Each hop is another owner who can break your code.
Open the final destination directly. If the final page is gone, the QR code is innocent — fix the page.
If the final page loads but the short link does not, the redirect record is dead: deleted, downgraded, or orphaned when an account lapsed.

That distinction decides the fix. A dead page is fixed on your site. A dead redirect is fixed in the redirect service — or not at all, if you have lost access to it. A code that scans on one phone but not another is a third thing entirely: a print problem, covered below.

Tracing the redirect chain in code

If you have the short URL, you can inspect its hop chain instead of guessing. This snippet follows redirects manually and logs each step. It works best for same-origin links or hosts that allow cross-origin requests; many short-link hosts block browser fetches with CORS, in which case use your browser's Network tab or curl -I on the command line instead — the idea is the same, only the tool changes.

async function traceRedirect(startUrl, maxHops = 5) {
  let url = startUrl;
  for (let hop = 0; hop < maxHops; hop++) {
    const response = await fetch(url, { redirect: "manual" });
    const next = response.headers.get("location");
    console.log(`Hop ${hop}: ${response.status} ${url}`);
    if (!next) {
      console.log("Chain ends here. This is the final destination.");
      return url;
    }
    url = new URL(next, url).href;
  }
  console.log("Stopped after max hops — check for a redirect loop.");
  return url;
}

// Example: traceRedirect("https://short.example/abc123");

Read the output like a detective. A chain that ends in a 404 means the destination moved. A chain that ends at a domain parking page means the redirect domain or record is gone. A chain that loops means someone wired two redirects to point at each other. A chain you cannot fetch from the browser at all is a reminder that the redirect hop is infrastructure you do not control — which is exactly the risk this article is about.

One honest caveat about that snippet: redirect: "manual" in a browser returns an opaque response for cross-origin redirects, and the location header is only readable when the host permits it. Do not treat a blocked fetch as proof the link is dead. Treat it as proof you need a different tool — Network tab, curl, or a server-side check — before you conclude anything.

The print failures that look like link failures

Not every dead code is a dead link. Some codes fail before the network is even involved:

Size. A code printed too small leaves no margin for shaky hands or weak cameras. The ToolkitLoop generator suggests about 25 mm or larger for print; posters and packaging need more, because viewing distance grows with the surface.
Contrast and polarity. Readers expect dark modules on a light background. Light-grey on white, colour-on-colour, or reversed white-on-black codes look designed and scan badly on at least some phones.
Logo coverage. A centre logo is safe when it stays small and the error correction level is high. Error correction levels run L, M, Q, and H, from least to most redundant data. A big logo on level L eats modules the reader cannot reconstruct; the same logo on level H often survives.
Quiet zone and distortion. The blank border around a code is part of the code. Crop it, stretch the code to fit a banner, or wrap it around a curved bottle, and even a perfect link will struggle.

The practical test is boring and effective: print the final file, scan it on two different phones, at the real distance, in realistic light. A code that only works on your own phone in perfect light is not done.

Why static is the default I ship

This is where the disclosure and the engineering meet. The generator I built at ToolkitLoop creates static codes only: the content is encoded in the image, generation happens locally in your browser, there is no redirect layer, and the downloaded file carries no watermark. You can try it here: https://toolkitloop.com/qr-code-generator

That choice trades away one feature — you cannot change the destination after printing — in exchange for removing an entire class of failure. There is no redirect account to lapse, no short domain to park, and no subscription keeping your printed posters alive. What can still break is the destination itself: if you delete the menu page the code points to, the code will faithfully deliver visitors to a 404. That is a website problem with a website fix, not a QR problem.

Static is not the right answer for everything. If you genuinely need to swap a campaign destination after printing, a dynamic code — ideally on a domain you control — is the honest tool for that job. But if the destination is stable — a homepage, a permanent menu, contact details, Wi-Fi credentials — paying for redirect machinery you will forget to maintain is how "free QR codes" end up with an expiry story.

A checklist before your next print run

Is the payload the final address, or a pointer you will have to maintain?
Does the final address load, right now, in a private browser window?
Is the code at least about 25 mm for handheld print, larger for distance viewing?
Is the contrast dark-on-light, with the quiet zone intact and no stretching?
Is any centre logo small, with error correction set high enough to cover it?
Have two different phones scanned the final file at the real distance?
Did you download SVG for print, reserving PNG for tools that specifically need a raster file?

If you can answer yes to all of those, the code you print is about as durable as a printed link can be. If you cannot, the failing item on that list is your fix — and it is almost never "make the squares prettier."

Now the hook I promised: how do you trace a suspicious redirect chain in your own stack — browser Network tab, curl -I, or a server-side check? And have you ever found a chain with a hop you did not know existed? I am curious which tool caught it, because that hidden hop is usually the one that breaks first.

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.

DEV Community: bowen Tse

I Built a Batch Image Resizer That Never Uploads a Photo

The annoying version of this problem

Fit, crop, pad: three rectangles, three promises

The batch problem is not the loop

Upscaling: the honest limitation

Three lessons I would keep for the next image tool

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

The naive split fails in specific, predictable places

The browser already has a segmenter: use it

Sentences, paragraphs and reading time are estimates, not facts

Why counters disagree — and what to tell users

Building it locally is the whole point

The checklist I would ship

Why Dynamic QR Codes Break: A Static-Code Fix for Devs

The mental model most people get wrong

A one-minute diagnosis you can actually run

Tracing the redirect chain in code

The print failures that look like link failures

Why static is the default I ship

A checklist before your next print run

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

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

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