DEV Community: sharefun2023

Base64 decoding: padding, UTF-8, and the atob() trap

sharefun2023 — Mon, 21 Sep 2026 12:06:14 +0000

Most Base64 bugs I have debugged were not crypto bugs. They were text-encoding bugs wearing a Base64 costume — or decoders being far more permissive than anyone assumed. Here are the five that keep showing up, each one measured rather than remembered.

1. `atob()` does not return text

Base64 encodes bytes, not characters. atob() returns a "binary string": one character per byte, char codes 0–255. Non-ASCII text (i.e. anything UTF-8) comes back as mojibake:

atob('5paH5Lu2');   // "æä»¶"  ← not what you meant

The fix is one extra step, and it is always the same step:

const bytes = Uint8Array.from(atob(b64), c => c.charCodeAt(0));
const text  = new TextDecoder('utf-8').decode(bytes);   // "文件"

Newer engines are getting a native helper (Uint8Array.fromBase64()), but the split is real: Chrome (v153) has it and Node 24 does not — I checked both on this machine, side by side. Until every runtime you target agrees, TextDecoder is the form that works everywhere.

2. Padding is structure, not payload

Base64 packs 3 bytes into 4 characters. When the byte count is not divisible by 3, = fills out the last group. Two useful consequences:

Browsers accept missing padding: atob('aGVsbG8') returns 'hello' without complaint.
length % 4 === 1 is impossible. If you compute that, the string was truncated somewhere upstream — not "recovered" by adding =. atob('a') throws InvalidCharacterError, which is the correct behaviour being politely demonstrated.

3. URL-safe Base64 is a different alphabet

JWT segments, S3 presigned URLs, anything passed through a query string: + becomes -, / becomes _, and the = padding is usually stripped. atob() rejects those two characters outright:

atob('a-b_');   // InvalidCharacterError

So convert the alphabet before decoding, and re-add the padding:

function b64urlToText(s) {
  s = s.replace(/-/g, '+').replace(/_/g, '/');
  s += '='.repeat((4 - (s.length % 4)) % 4);
  return new TextDecoder('utf-8')
    .decode(Uint8Array.from(atob(s), c => c.charCodeAt(0)));
}

4. Node's decoder never complains, and that is the trap

Buffer.from(s, 'base64') is deliberately lenient. It ignores characters outside the alphabet, it ignores truncation, and it never throws. Measured on Node 24:

Buffer.from('aGVs*bG8=', 'base64').toString();  // 'hello'  ← the * was silently dropped
Buffer.from('aGVsb',    'base64').toString();   // 'hel'    ← truncated input, no error
Buffer.from('a-b_',     'base64');              // 'k\ufffd\ufffd' ← URL-safe chars, decoded as garbage

Which means "it decoded fine in Node" proves nothing at all: you can be handed a mangled string, get a plausible-looking result, and only find out much later. If the input can come from anywhere you do not control, validate before decoding:

if (!/^[A-Za-z0-9+/]*={0,2}$/.test(s) || s.length % 4 === 1) {
  throw new Error('not valid Base64');
}

5. Whitespace is a non-issue (PEM, MIME, emails)

Both browser atob() and Node strip ASCII whitespace, so line-wrapped PEM bodies and MIME blobs decode as-is: atob('aGVs\n bG8=') → 'hello'. The classic failure is never whitespace — it is everything in section 4.

Where the "free online decoder" pattern actually leaks

Look at what gets pasted into a Base64 decoder. It is rarely a toy string: it is a session cookie, a signed token, an auth header copied out of a log line. If it is a JWT, the payload is a live credential until it expires, and it has just been POSTed to someone's server. That is also why token decoders make an attractive target — their request logs are full of credentials that still work.

Browser devtools will decode for you, but the fiddly cases (URL-safe input, invalid bytes, known-truncation, a hex view of the decoded bytes) are what made me keep a decoder open in a browser tab. Mine is at 23232322.xyz/base64-decode — client-side only, nothing uploaded, and it explains why an input is rejected instead of just failing. The encoder pair is at base64-encode, and if you are pasting actual tokens, the one that verifies signatures (HS256/384/512 secrets and RS/ES256–512 public keys) is the JWT decoder & debugger.

TL;DR

Symptom	Cause	Fix
`æä»¶` instead of real text	`atob()` returns bytes-as-chars	`new TextDecoder('utf-8').decode(Uint8Array.from(atob(s), c => c.charCodeAt(0)))`
`InvalidCharacterError` on `-` / `_`	URL-safe alphabet	swap `-_` → `+/`, re-pad
Throws on a 5-char segment	`length % 4 === 1`	input is truncated; fix upstream
Node decodes garbage without error	`Buffer.from` silently drops junk	regex-validate first
Line-wrapped PEM block	—	nothing to do, whitespace is ignored

I Counted How Many Free Dev Tools Quietly Upload Your Data. Then I Built 80 That Don't.

sharefun2023 — Sun, 13 Sep 2026 12:05:30 +0000

Paste a JWT into a "free online JWT debugger." Paste a config file into a "free JSON formatter."

Then open DevTools, hit the Network tab, and watch it POST your payload to api.something-saas.com/v1/parse.

I got annoyed enough to check. Of the first dozen "free" tools I tried, eight shipped data off the device. Some had a privacy policy. Some had a privacy policy that said "we may share data with partners." Your production tokens, in a partner's S3 bucket.

Most of them weren't even doing it to be evil. They just built a Next.js app, needed the logic somewhere, and the server was already there. Formatter on the server. Base64 decode on the server. For a 3-line JSON.stringify.

The part that actually costs you

It's not just privacy theater. Server-side tooling has real costs you pay every day:

Latency. Round-trip to a region that isn't yours, on a connection that isn't yours. My regex tester took ~400ms to say "no match."
Rate limits and paywalls. Free tier hits you at 10 operations. The tool that was "free" is now a $9/mo subscription for btoa.
Availability. Their server goes down, your tool goes down. Great during an incident, when you actually need to decode something.
Offline. On a plane, on a locked-down corporate network, the tool is gone.

Every one of those problems disappears if the code runs in the browser tab you already have open.

What client-side actually means

There is no API. There is no fetch to a backend. Network stays empty except for the static assets. Concretely:

// Base64, no server. 2 lines and no data leaves the tab.
const encode = (s) => btoa(String.fromCharCode(...new TextEncoder().encode(s)));
const decode = (s) => new TextDecoder().decode(Uint8Array.from(atob(s), c => c.charCodeAt(0)));

// JWT verify with a real signature check, in-page.
// WebCrypto handles HS256/384/512 and RS/ES via importKey.
const [h, p, s] = jwt.split(".");
const key = await crypto.subtle.importKey(
  "raw", new TextEncoder().encode(secret),
  { name: "HMAC", hash: "SHA-256" }, false, ["verify"]
);
const sig = Uint8Array.from(
  atob(s.replace(/-/g, "+").replace(/_/g, "/")), c => c.charCodeAt(0)
);
const ok = await crypto.subtle.verify(
  "HMAC", key, sig, new TextEncoder().encode(`${h}.${p}`)
);

That's the whole "backend." The <input> is the API.

The interesting cases are where people assume you need a server:

Task	Why people think it needs a server	How it's actually done client-side
SQL formatting	"Parsing is hard"	Tokenizer + formatter in a Web Worker — keeps the main thread at 60fps
Image conversion	"Encoding is server work"	Canvas + `toBlob('image/webp')`
SVG to PNG	"Rasterization needs a service"	Draw the SVG into a canvas via a data-URI image
Regex testing	"Sandboxing"	It's a regex. `RegExp` has been in the engine forever
Hashing (SHA/MD5)	"Performance"	`crypto.subtle`, native speed

WebCrypto also gives you something the SaaS tools don't: the key never crosses the wire. A server-side JWT verifier has to receive your signing secret to check a signature. That's a much bigger deal than the payload leak.

What I built

23232322.xyz — 80+ tools, one page each, no build step. JSON formatter and validator, Base64 encode/decode, regex tester, JWT debugger with real HS256/384/512 and RS/ES256-512 verification, hash generators, UUID, URL encode/decode, diff checker, HTML minifier, and a bunch more.

No account. No upload. No analytics on your input. Source for each page is plain HTML + vanilla JS, so you can read it and confirm nothing is being sent anywhere.

How to check any tool yourself in 20 seconds

Before you trust any "free online X":

Open DevTools → Network.
Filter to Fetch/XHR.
Use the tool with obvious dummy data ({"test":1}).
If a request appears with your input in the body — that data left your machine.

Do that to my tools too. It's the point.

If a tool can't be written this way, it's because it needs a real backend. Most of them don't. They just needed somewhere to put the code.

The whole set is at 23232322.xyz.

Why Your SVG-to-PNG Conversion Looks Wrong (And How to Fix It in the Browser)

sharefun2023 — Thu, 10 Sep 2026 12:34:26 +0000

Why Your SVG-to-PNG Conversion Looks Wrong (And How to Fix It in the Browser)

You export an icon to PNG and it comes back with the wrong font, a black background instead of transparency, or soft, blurry edges. Nine times out of ten the bug is not in your export code — it's in the assumption that a browser rasterizes SVG the same way a design tool does.

Converting SVG to PNG in the browser is really just three steps: turn the markup into an image, draw that image onto a canvas, and read the canvas back as a PNG. The canvas is doing all the work. Everything that looks wrong comes from what the browser refuses to load while doing it.

Here is the full pipeline plus the seven failure modes I hit while building a client-side converter with no server, no uploads, and no dependencies.

The pipeline

async function svgToPng(svgText, { scale = 2, background = null } = {}) {
  // 1. Parse and normalise the SVG
  const doc = new DOMParser().parseFromString(svgText, 'image/svg+xml');
  const svg = doc.documentElement;
  if (svg.querySelector('parsererror')) throw new Error('Invalid SVG');

  // 2. Resolve the intrinsic size
  const vb = svg.getAttribute('viewBox');
  let [, , w, h] = (vb || '0 0 300 150').split(/[\s,]+/).map(Number);
  w = w || Number(svg.getAttribute('width')) || 300;
  h = h || Number(svg.getAttribute('height')) || 150;

  // Force explicit pixel dimensions (see pitfall 3)
  svg.setAttribute('width', w);
  svg.setAttribute('height', h);
  svg.setAttribute('xmlns', 'http://www.w3.org/2000/svg');

  // 3. Serialise to a blob URL the <img> can load
  const blob = new Blob([new XMLSerializer().serializeToString(svg)], {
    type: 'image/svg+xml;charset=utf-8',
  });
  const url = URL.createObjectURL(blob);

  try {
    const img = await loadImage(url);

    // 4. Draw at scale for a crisp result
    const canvas = document.createElement('canvas');
    canvas.width = Math.round(w * scale);
    canvas.height = Math.round(h * scale);
    const ctx = canvas.getContext('2d');

    if (background) {
      ctx.fillStyle = background;
      ctx.fillRect(0, 0, canvas.width, canvas.height);
    }
    ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

    // 5. Export
    return await new Promise((resolve, reject) =>
      canvas.toBlob(
        (b) => (b ? resolve(b) : reject(new Error('Canvas is tainted'))),
        'image/png'
      )
    );
  } finally {
    URL.revokeObjectURL(url);
  }
}

function loadImage(src) {
  return new Promise((resolve, reject) => {
    const img = new Image();
    img.onload = () => resolve(img);
    img.onerror = () => reject(new Error('SVG failed to rasterise'));
    img.src = src;
  });
}

Roughly 40 lines, and it works — for a subset of SVG. The rest of this post is about that subset.

Pitfall 1: external resources are silently blocked

This is the big one. When an SVG is loaded through an <img>, the browser treats it as an image, not a document. Images do not get to fetch subresources. So these all fail silently:

<image href="logo.png"> pointing at a file or a URL
@font-face rules inside a <style> block
@import of a stylesheet
anything behind url(#…) that resolves to a network request

There is no error. No console warning. The element just renders as nothing, and you get a PNG with a hole in it. The fix is to inline everything first — convert referenced images to data: URIs, and turn text into paths before export if the font matters (see next pitfall).

Pitfall 2: fonts fall back to whatever is installed

Same root cause, different symptom. Your SVG says font-family: "Inter", the browser rasterizing it has never heard of Inter, and you get Helvetica or DejaVu instead. Text reflows, line breaks move, and a logo turns into something slightly wrong that nobody can name.

Two reliable options:

Convert text to paths in the source file. The output is then font-independent everywhere, forever. This is what text-to-path / object-to-path does in your editor.
Use only fonts you can guarantee — generic families (sans-serif, serif, monospace) or system stacks. They render, just never the exact file you designed with.

If you keep live text, expect the browser's metrics, not your design tool's metrics.

Pitfall 3: no width/height, no pixels

An SVG with only a viewBox has no intrinsic size:

<svg viewBox="0 0 24 24" xmlns="http://www.w3.org/2000/svg">

That's perfectly valid SVG, and Chrome will happily display it when sized by CSS. But when you load the same markup into an <img>, several browsers report naturalWidth as 0 — and drawImage with a zero-sized source throws or draws nothing. The export "succeeds" and produces an empty or 1×1 PNG.

Fix: always set explicit width and height attributes on the root <svg> before serialising, derived from the viewBox. That's the svg.setAttribute('width', w) line above, and it's the single most common cause of "my converter only works on some files."

Pitfall 4: blurry output on retina

A canvas has two sizes: its CSS size and its backing-store size. Only the backing store defines how many real pixels you get. If you set the canvas to 300×300 and draw a 300×300 icon into it, you get a 300×300 PNG — which is correct, and looks soft on a 2× display because there simply aren't enough pixels.

Set the backing store bigger and scale the drawing:

canvas.width = Math.round(w * scale);   // scale = 2 for 2x
canvas.height = Math.round(h * scale);
ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

Because SVG is resolution-independent, you can go as high as you like — scale = 4 on a 24px icon gives you 96×96 real pixels. Just remember the dimensions you multiply here are the output pixel dimensions; a 4000px export of a complex icon is a 4000px PNG, not a free lunch.

Pitfall 5: "transparent" isn't

canvas starts fully transparent, so toBlob('image/png') gives you real alpha by default. The surprise is the other direction: designers export SVGs with a white <rect> covering the artboard, so your "transparent" PNG arrives with a white box painted over the background. Nothing to fix in code — it's in the source file.

If you do want a flat background (say for a JPG or for email), paint it before drawing, since drawImage composites rather than replaces:

if (background) {
  ctx.fillStyle = background;
  ctx.fillRect(0, 0, canvas.width, canvas.height);
}
ctx.drawImage(img, 0, 0, canvas.width, canvas.height);

Pitfall 6: filters and `foreignObject` are renderer-specific

feGaussianBlur, feTurbulence, mix-blend-mode, and <foreignObject> are the parts of SVG that every engine implements a little differently. A blur that looks right in Chrome can look banded in Firefox and glossier in Safari. <foreignObject> — the trick for rendering HTML inside SVG — is the least portable feature in the spec, and it's also the fastest way to get a canvas that won't export (next pitfall).

If your target is a PNG that looks identical for everyone, flatten these effects in the source file or accept per-browser drift.

Pitfall 7: the tainted canvas

canvas.toBlob() throws SecurityError when the canvas is "tainted" — meaning something cross-origin was drawn into it. With pure SVG-as-image this is mostly moot because external resources are blocked anyway, but it comes straight back when you compose a design: draw a user's cross-origin photo onto the canvas, then try to export, and the export dies even though the pixels are right there on screen.

Two ways out:

Serve the images with permissive CORS headers and set img.crossOrigin = 'anonymous' before setting src. (Order matters; setting it after triggers a second, uncached request or an outright failure.)
Do the compositing server-side, which is exactly the dependency a client-side tool is trying to avoid.

This is also why the classic "paste a URL and convert" trick fails: the remote SVG has to be fetched with CORS enabled, or the browser blocklists it before a single pixel is drawn.

The checklist

Before you blame your code, check the source file:

Everything inlined — images as data: URIs, fonts as paths or generic families.
Explicit width and height on the root <svg>, matching the viewBox.
xmlns="http://www.w3.org/2000/svg" present after serialisation.
No currentColor and no var(--…) — outside a page context there is nothing to inherit from, so they resolve to defaults (usually black).
No page CSS assumptions — styles must live inside the SVG's own <style> or as attributes.

And in your code:

Backing store scaled up for retina, not just CSS size.
URL.revokeObjectURL in a finally block, or you leak the blob on every conversion.
Paint a background before drawImage if the format has no alpha channel.

I built one of these

These are the exact edge cases I hit while building imgloft.com — a free browser-side image toolset for SVG→PNG, PNG compression, resizing and cropping. It does the rasterisation on your device with the pipeline above, so nothing is uploaded and there's no queue to wait in. If you just want to convert a file rather than debug one:

SVG to PNG converter — scale 1×–4×, transparent or flat background
The longer guide version of this post — including a comparison table of browser-side vs server-side conversion

If you've hit a rasterisation bug that isn't on this list, I want to hear it — drop it in the comments and I'll reproduce it.

How I Built a Free SVG to PNG Converter in 1 Hour

sharefun2023 — Tue, 04 Aug 2026 08:05:54 +0000

I needed a quick way to convert SVG icons to PNG for a project. Every online converter I found required uploading files to a server — slow, privacy-invasive, and overkill for a 2KB icon.

So I built imgloft.com — a free, client-side SVG to PNG converter that works entirely in your browser. No uploads, no server, 100% private.

The Problem

Most online SVG-to-PNG tools follow the same pattern:

Upload your SVG to their server
Server runs a conversion library (ImageMagick, librsvg, etc.)
Download the result

This is fine for occasional use, but it breaks down when:

You're working with sensitive design assets
The file is large and upload takes forever
You're offline or behind a restrictive firewall
You just want to convert a tiny icon without waiting

The 1-Hour Solution

The entire converter is built with three browser APIs:

// 1. Read the SVG file
const reader = new FileReader();
reader.onload = (e) => {
  const svgText = e.target.result;

  // 2. Draw it on a canvas at the desired resolution
  const img = new Image();
  const svgBlob = new Blob([svgText], {type: 'image/svg+xml'});
  img.src = URL.createObjectURL(svgBlob);

  img.onload = () => {
    const canvas = document.createElement('canvas');
    canvas.width = img.width;
    canvas.height = img.height;
    const ctx = canvas.getContext('2d');
    ctx.drawImage(img, 0, 0);

    // 3. Export as PNG
    canvas.toBlob((blob) => {
      const url = URL.createObjectURL(blob);
      // Trigger download
    }, 'image/png');
  };
};
reader.readAsText(file);

That's it. Three APIs, zero dependencies, zero server cost.

Why It Only Took 1 Hour

No backend. The entire tool runs in the browser using the Canvas API. No Express, no ImageMagick, no Docker container. Just a static HTML file served from Cloudflare Pages.

No auth. Users don't need accounts — they come, convert, and leave. No database, no user management, no session tokens.

No framework. Plain HTML, vanilla JavaScript, and a few lines of CSS. No React, no build step, no node_modules.

What I Learned

Client-side is underrated. The browser can do way more than we give it credit for. SVG rendering, image encoding, even basic image manipulation — all built in.

Ship the MVP. I could have spent weeks adding batch conversion, format options, color filters. Instead I shipped the core feature in an afternoon and let users tell me what they need.

Free tools attract real users. Within days of going live, Google started indexing the site. People are searching for "svg to png converter" — 40,000 times a month. The demand is real.

Try It Yourself

imgloft.com — drag any SVG, get a PNG instantly. Also includes compress, resize, and crop tools.

If you're thinking about building a micro-tool site, just do it. Ship the simplest version first. The browser is your backend.

Building a Client-Side SQL Formatter with Vanilla JS and Web Workers

sharefun2023 — Mon, 20 Jul 2026 15:35:46 +0000

Most SQL formatters process queries server-side. That means every time you click "Format", your SQL gets sent to a random backend — with no guarantee of what happens to it.

I wanted something different: a formatter where your data never leaves your browser.

The Stack

sqlformat.io is built with:

Vanilla JavaScript — no framework, no build step
sql-formatter — the formatting engine
Web Workers — formatting runs off the main thread so the UI stays snappy even on 1000+ line queries
Cloudflare Pages — zero-cost hosting with global edge caching

Architecture

User pastes SQL
  ↓
Main thread sends to Web Worker
  ↓
Worker calls sql-formatter with dialect-specific options
  ↓
Formatted SQL sent back to main thread
  ↓
Rendered with syntax highlighting (no library needed — just regex + <span>)

Key insight: the sql-formatter library alone is ~50KB gzipped. Running it in a Web Worker means the main thread never blocks, and the user can keep typing while large queries format in the background.

Why No Server?

Privacy — zero bytes leave the user browser
Offline — works after the page loads, no internet needed
Scale — no server costs, no rate limits, no API keys
Speed — no round trip, instant formatting

Lessons Learned

Web Workers are underrated — they turn a potentially laggy text processor into a buttery-smooth UX
SQL dialects are deceptively complex — MySQL vs PostgreSQL vs BigQuery all have different quoting rules, and the formatter needs to handle inline comments and dollar-quoted strings that span multiple lines
Regex-based syntax highlighting works surprisingly well for SQL — you do not need a parser, just a few well-placed regex patterns for keywords, strings, numbers, and comments

Try it: sqlformat.io

Source: github.com/sharefun2023/sqlformat.io

I Got Tired of Slow SQL Formatters That Upload My Queries — So I Built a Free One

sharefun2023 — Mon, 20 Jul 2026 15:35:08 +0000

I write a lot of SQL every day. And every online formatter I tried had the same problems:

Uploads queries to their server — privacy nightmare when you are working with production schema
Tiny text area — cannot handle 500+ line queries without lag
3 ads before you even see the formatted output

So I built sqlformat.io — a no-BS SQL formatter.

What It Does

Client-side only — everything runs in YOUR browser via Web Worker. Zero bytes leave your device
15+ SQL dialects — MySQL, PostgreSQL, SQLite, BigQuery, Snowflake, T-SQL, and more
No signup, no ads, no upload — ever
Instant — paste, click Format, done

Why I Built It

I got tired of copy-pasting production queries into random websites and wondering where they ended up. With sqlformat.io, you can disconnect your internet after the page loads and keep formatting offline.

Extra Tools Included

It is not just a formatter — the site has several free SQL tools:

Diff — compare two SQL queries side by side
Minify/Compress — strip whitespace for embedding in code
Validate — syntax check across dialects
ER Diagram — visualize table relationships
SQL to JSON — convert query results
Data Generator — generate test data
Explain Visualizer — MySQL/PostgreSQL EXPLAIN output as a tree

Tech Stack

Vanilla JS + sql-formatter library, hosted on Cloudflare Pages. All formatting runs in a Web Worker so the UI stays responsive even on huge queries.

Open source: github.com/sharefun2023/sqlformat.io

Would love feedback from folks who format SQL daily!

DEV Community: sharefun2023

Base64 decoding: padding, UTF-8, and the atob() trap

1. atob() does not return text

2. Padding is structure, not payload

3. URL-safe Base64 is a different alphabet

4. Node's decoder never complains, and that is the trap

5. Whitespace is a non-issue (PEM, MIME, emails)

Where the "free online decoder" pattern actually leaks

TL;DR

I Counted How Many Free Dev Tools Quietly Upload Your Data. Then I Built 80 That Don't.

The part that actually costs you

What client-side actually means

What I built

How to check any tool yourself in 20 seconds

Why Your SVG-to-PNG Conversion Looks Wrong (And How to Fix It in the Browser)

Why Your SVG-to-PNG Conversion Looks Wrong (And How to Fix It in the Browser)

The pipeline

Pitfall 1: external resources are silently blocked

Pitfall 2: fonts fall back to whatever is installed

Pitfall 3: no width/height, no pixels

Pitfall 4: blurry output on retina

Pitfall 5: "transparent" isn't

Pitfall 6: filters and foreignObject are renderer-specific

Pitfall 7: the tainted canvas

The checklist

I built one of these

How I Built a Free SVG to PNG Converter in 1 Hour

The Problem

The 1-Hour Solution

Why It Only Took 1 Hour

What I Learned

Try It Yourself

Building a Client-Side SQL Formatter with Vanilla JS and Web Workers

The Stack

Architecture

Why No Server?

Lessons Learned

I Got Tired of Slow SQL Formatters That Upload My Queries — So I Built a Free One

What It Does

Why I Built It

Extra Tools Included

Tech Stack

1. `atob()` does not return text

Pitfall 6: filters and `foreignObject` are renderer-specific