DEV Community: Zihang Dong 董子航

I Built a Browser-Based Pixel Art Converter Using Canvas, Median Cut, and Floyd-Steinberg Dithering

Zihang Dong 董子航 — Sun, 12 Apr 2026 03:59:27 +0000

Pixel art is everywhere — indie games, NFT avatars, social media profiles, retro-themed designs. But there's a huge gap between "pixelating an image" (which looks terrible) and actual pixel art (which looks intentional and beautiful).

I built a free Pixel Art Converter that bridges this gap using 5 classic computer science algorithms, all running in the browser via the Canvas API. No server uploads, no AI — just math.

Here's exactly how it works under the hood.

The Problem: Pixelation ≠ Pixel Art

If you just shrink an image and scale it back up, you get a blurry mosaic. Real pixel art has:

Limited color palettes (4–64 colors)
Dithering patterns that simulate smooth gradients
Dark outlines around shapes
Vibrant, saturated colors

My converter applies all four of these automatically. Let me walk through each algorithm.

Algorithm 1: Downsampling

The simplest step. I draw the source image onto a tiny canvas (e.g., 64px wide), then scale it back up using imageSmoothingEnabled = false to preserve hard pixel edges.

// Draw source onto tiny canvas
const smallCanvas = document.createElement('canvas');
smallCanvas.width = pixelRes; // e.g., 64
smallCanvas.height = Math.round(img.height * (pixelRes / img.width));
const ctx = smallCanvas.getContext('2d');
ctx.drawImage(img, 0, 0, smallCanvas.width, smallCanvas.height);

// Scale back up with nearest-neighbor interpolation
outputCtx.imageSmoothingEnabled = false;
outputCtx.drawImage(smallCanvas, 0, 0, outputWidth, outputHeight);

Resolution recommendations:

16–32px → Game sprites, tiny icons
64px → Sweet spot for most images
128–256px → Detailed portraits, wallpapers

Algorithm 2: Median Cut Color Quantization

This is where it gets interesting. Real pixel art uses limited palettes. I use the median cut algorithm to intelligently reduce colors.

The idea: treat every pixel as a point in 3D RGB space. Recursively split the color space into buckets by finding the channel (R, G, or B) with the widest range and splitting at the median.

function medianCut(pixels, numColors) {
    let buckets = [pixels];

    while (buckets.length < numColors) {
        // Find the bucket with the widest color range
        let targetBucket = findWidestBucket(buckets);

        // Find which channel (R, G, B) has the widest range
        let channel = findWidestChannel(targetBucket);

        // Sort by that channel and split at the median
        targetBucket.sort((a, b) => a[channel] - b[channel]);
        let mid = Math.floor(targetBucket.length / 2);

        buckets.push(targetBucket.slice(0, mid));
        buckets.push(targetBucket.slice(mid));
    }

    // Each bucket's average color becomes one palette entry
    return buckets.map(bucket => averageColor(bucket));
}

After building the palette, each pixel gets mapped to its closest palette color using Euclidean distance in RGB space.

Fewer colors = more retro:

4 colors → Game Boy style
16 colors → NES/CGA era
32–64 colors → Best balance for most photos

Algorithm 3: Floyd-Steinberg Dithering

This is what separates a real pixel art converter from a cheap pixelator. Dithering distributes quantization error to neighboring pixels, creating the illusion of more colors through dot patterns.

Without dithering: harsh flat color blocks (the "mosaic" look).
With dithering: smooth gradients made of alternating dots — exactly like 8-bit and 16-bit era graphics.

function floydSteinbergDither(imageData, palette) {
    const { data, width, height } = imageData;

    for (let y = 0; y < height; y++) {
        for (let x = 0; x < width; x++) {
            let idx = (y * width + x) * 4;
            let oldR = data[idx], oldG = data[idx+1], oldB = data[idx+2];

            // Find nearest palette color
            let [newR, newG, newB] = findClosest(oldR, oldG, oldB, palette);
            data[idx] = newR; data[idx+1] = newG; data[idx+2] = newB;

            // Calculate error
            let errR = oldR - newR, errG = oldG - newG, errB = oldB - newB;

            // Distribute error to neighbors
            distributeError(data, x+1, y,   width, height, errR, errG, errB, 7/16);
            distributeError(data, x-1, y+1, width, height, errR, errG, errB, 3/16);
            distributeError(data, x,   y+1, width, height, errR, errG, errB, 5/16);
            distributeError(data, x+1, y+1, width, height, errR, errG, errB, 1/16);
        }
    }
}

The 7/16, 3/16, 5/16, 1/16 distribution creates a natural, organic pattern that avoids visual banding.

Algorithm 4: Sobel Edge Detection

Hand-drawn pixel art almost always has dark outlines. I use the Sobel operator to automatically detect and darken edges.

The Sobel operator uses two 3×3 convolution kernels to calculate horizontal and vertical gradients:

const sobelX = [[-1, 0, 1], [-2, 0, 2], [-1, 0, 1]];
const sobelY = [[-1, -2, -1], [0, 0, 0], [1, 2, 1]];

function sobelEdgeDetect(imageData) {
    // Convert to grayscale first
    for (let y = 1; y < height - 1; y++) {
        for (let x = 1; x < width - 1; x++) {
            let gx = convolve(imageData, x, y, sobelX);
            let gy = convolve(imageData, x, y, sobelY);
            let magnitude = Math.sqrt(gx * gx + gy * gy);

            if (magnitude > threshold) {
                // Darken this pixel proportionally
                darkenPixel(imageData, x, y, magnitude);
            }
        }
    }
}

Where the gradient magnitude exceeds a threshold, pixels get darkened — creating outlines that naturally follow contours.

Algorithm 5: HSL Saturation Boost

Pixel art uses bold, vibrant colors. Before quantization, I convert each pixel to HSL, boost saturation (default 130%), and convert back to RGB.

function boostSaturation(r, g, b, factor) {
    let [h, s, l] = rgbToHsl(r, g, b);
    s = Math.min(1, s * factor); // Boost but clamp at 1.0
    return hslToRgb(h, s, l);
}

150–200% saturation gives that vibrant retro game aesthetic.

Retro Console Presets

For instant results, I built presets that emulate real gaming hardware:

Preset	Colors	Resolution	Special
Game Boy	4 green shades	48px	Hardcoded 1989 palette
NES	54 colors	64px	Authentic NES color table
SNES	128 colors	128px	Median cut quantization
CGA	16 colors	64px	IBM PC palette

The Game Boy and NES presets use exact hardware palettes rather than median cut — every color matches what the original console could display.

The Pipeline

Here's the full processing order:

Source Image
  → Saturation boost (HSL)
  → Downsample to pixel grid (Canvas)
  → Median cut quantization (or preset palette)
  → Floyd-Steinberg dithering (optional)
  → Sobel edge detection + outline darkening (optional)
  → Scale up with nearest-neighbor
  → Output

Everything runs on a single <canvas> element using getImageData() and putImageData(). No WebGL, no Web Workers, no external libraries.

Privacy: Zero Uploads

The entire tool runs in the browser. Your image never touches a server. Close the tab and all data is gone. This is possible because the Canvas API gives us direct pixel-level access — we don't need any server-side image processing.

Try It

→ Pixel Art Converter — Free, No Sign-up

Drop any image, adjust resolution and colors, toggle dithering and outlines, try the Game Boy preset — and download your pixel art as PNG.

Built as part of ToolKnit — 33+ free browser-based tools for PDF, image, video, audio, and more.

What algorithms would you add? I'm considering palette import (load a .pal file) and animated GIF pixel art conversion. Let me know in the comments!

Building a Browser-Based Keyboard Tester with Vanilla JavaScript

Zihang Dong 董子航 — Sat, 11 Apr 2026 07:45:30 +0000

Have you ever bought a new mechanical keyboard only to discover a dead switch two weeks later — past the return window? Or spilled coffee on your laptop and wondered which keys survived?

I built a free keyboard tester that runs entirely in the browser. No downloads, no backend, no data collection. Just open the page, press keys, and see which ones work.

In this post, I'll walk through the key technical decisions and JavaScript patterns I used to build it.

The Core Idea

Display a virtual keyboard on screen. When the user presses a physical key, the corresponding virtual key lights up. Simple concept, but there are a few tricky parts:

Mapping physical keys to virtual keys — Not all keyboards have the same layout
Capturing ALL key presses — Including Tab, F-keys, and other keys browsers like to hijack
Counting keystrokes — For detecting chattering (double-firing keys)
N-Key Rollover testing — Tracking multiple simultaneous key holds

Key-to-Element Mapping

Each virtual key in the HTML has a data-key attribute matching the KeyboardEvent.code value:

<div class="key" data-key="KeyA">A</div>
<div class="key" data-key="Space">Space</div>
<div class="key" data-key="ShiftLeft">Shift</div>

I chose event.code over event.key because code represents the physical key position, not the character it produces. This means the tester works regardless of keyboard language or layout (QWERTY, AZERTY, Dvorak, etc).

function getKeyElement(code) {
    return document.querySelector('.key[data-key="' + code + '"]');
}

Capturing Every Key Press

Browsers intercept certain keys by default: Tab switches focus, F5 refreshes, F11 toggles fullscreen. To capture these, I use preventDefault() on both keydown and keyup events, with useCapture: true:

document.addEventListener('keydown', function(e) {
    e.preventDefault();
    e.stopPropagation();

    const code = e.code;
    const keyEl = getKeyElement(code);

    if (keyEl) {
        keyEl.classList.add('active');     // Visual press feedback

        if (!testedKeys.has(code)) {
            testedKeys.add(code);
            keyEl.classList.add('tested'); // Permanent "tested" state
            updateStats();
        }
    }

    return false;
}, true); // useCapture = true

And the corresponding keyup handler to remove the "active" visual state:

document.addEventListener('keyup', function(e) {
    e.preventDefault();
    e.stopPropagation();

    const keyEl = getKeyElement(e.code);
    if (keyEl) keyEl.classList.remove('active');
    return false;
}, true);

Preventing Browser Shortcuts

Some keys need extra prevention at the window level:

window.addEventListener('keydown', function(e) {
    if (e.key === 'Tab' || e.key === 'F1' || e.key === 'F5' || 
        e.key === 'F11' || e.key === 'F12') {
        e.preventDefault();
    }
});

This catches Tab (focus switching), F1 (help), F5 (reload), and F11/F12 (fullscreen/devtools) before the browser processes them.

The Keystroke Counter

This was a recent addition and probably the most useful feature for diagnosing keyboard problems. Mechanical keyboards can develop "chattering" — where one press registers as two or more inputs. This is caused by worn switch contacts bouncing.

The counter tracks every key press individually:

const keyCounts = {};
let totalKeystrokes = 0;

// Inside keydown handler:
keyCounts[code] = (keyCounts[code] || 0) + 1;
totalKeystrokes++;
updateKeystrokeUI(code, label);

The UI dynamically creates a card for each key, showing its press count. If a key registers 3+ presses, it's highlighted in amber as a potential chattering issue:

function updateKeystrokeUI(code, label) {
    let entry = document.getElementById('kc-' + code);
    if (!entry) {
        entry = document.createElement('div');
        entry.id = 'kc-' + code;
        entry.className = 'flex items-center justify-between ...';
        entries.appendChild(entry);
    }

    const count = keyCounts[code];
    const isHigh = count >= 3;
    entry.innerHTML = '<span class="' + (isHigh ? 'text-amber-400' : 'text-slate-300') + '">' 
        + label + '</span><span>' + count + (isHigh ? ' !' : '') + '</span>';
}

The reset function clears all counts without affecting the main keyboard test state:

window.resetKeystrokeCounter = function() {
    for (var k in keyCounts) delete keyCounts[k];
    totalKeystrokes = 0;
    document.getElementById('keystroke-entries').innerHTML = '';
};

Progress Tracking

Users need to know how many keys they've tested out of the total. The stats panel shows tested/total/percentage and color-codes the progress:

function updateStats() {
    const tested = testedKeys.size;
    const pct = Math.round((tested / totalKeysCount) * 100);

    document.getElementById('keys-pressed').textContent = tested;
    document.getElementById('keys-percent').textContent = pct + '%';

    // Color feedback
    const pctEl = document.getElementById('keys-percent');
    if (pct >= 100) {
        pctEl.className = '... text-emerald-400'; // Green = done
    } else if (pct >= 50) {
        pctEl.className = '... text-yellow-400';  // Yellow = halfway
    }
}

Virtual Key Clicks

Not everyone has a physical keyboard handy (maybe they're testing remotely). Virtual keys are clickable too:

allKeys.forEach(function(keyEl) {
    keyEl.addEventListener('click', function() {
        const code = this.getAttribute('data-key');
        this.classList.add('active');

        if (!testedKeys.has(code)) {
            testedKeys.add(code);
            this.classList.add('tested');
            updateStats();
        }

        // Keystroke counter for clicks too
        keyCounts[code] = (keyCounts[code] || 0) + 1;
        totalKeystrokes++;

        setTimeout(() => this.classList.remove('active'), 200);
    });
});

Lessons Learned

event.code > event.key — Always use code for physical key identification. key changes with language/layout.
useCapture: true is essential — Without it, some keydown events get swallowed before your handler runs.
A Set is perfect for tracking tested keys — O(1) lookups, no duplicates, and .size gives you the count for free.
Chattering detection needs a counter, not a boolean — Just knowing a key "was pressed" isn't enough. You need to know how many times it registered per intended press.
No framework needed — The entire tool is vanilla HTML + CSS + JS. It loads instantly and works offline. Sometimes the simplest stack is the best stack.

Try It

The keyboard tester is live at toolknit.com/tools/keyboard-tester.html. It's part of ToolKnit, a collection of 30+ free browser-based tools for files, images, video, and more.

If you have a keyboard collecting dust, plug it in and test it. You might be surprised what you find.

Have you built similar browser-based utilities? I'd love to hear about the edge cases you ran into. Drop a comment below!

I Analyzed 1,000 Professional Emails — Here Are the 5 Patterns That Get Replies

Zihang Dong 董子航 — Thu, 09 Apr 2026 08:25:15 +0000

Last year I built RewriteEmail, a free AI tool that rewrites professional emails. After processing thousands of email rewrites, clear patterns emerged about why some emails get responses and others get ignored.

This isn't theory — it's data from real users rewriting real emails. Here's what I found.

1. The First Sentence Determines Everything

The pattern: Emails that opened with context ("Following up on our Tuesday call about the Q3 budget") had a dramatically different tone than emails that opened with filler ("I hope this email finds you well").

The fix: Delete your first sentence. Whatever your second sentence is — that's your real opener. We noticed that the AI almost always removed or restructured the first line of user drafts.

❌ "I hope you're doing well. I wanted to reach out regarding..."
✅ "Following up on your question about the API migration timeline —"

The best first sentence answers: "Why am I reading this right now?"

2. One Ask Per Email — Always

The pattern: Emails with 3+ requests had a noticeably confused, rambling quality. Users would paste in emails asking for a meeting AND feedback AND approval AND a timeline update.

The fix: One email = one action item. If you need three things, either prioritize ruthlessly or send three short emails.

❌ "Could you review the deck, send me the budget numbers, 
    and confirm if Thursday works for the all-hands?"

✅ "Could you confirm if Thursday 2pm works for the all-hands? 
    I'll send the deck and budget questions separately."

I call this the "one reply, one action" rule. The recipient should be able to respond in under 60 seconds.

3. The "Apology Spiral" Kills Your Credibility

The pattern: A huge percentage of workplace emails we processed contained over-apologizing. Phrases like "Sorry to bother you," "I'm sorry if this is a stupid question," "Apologies for the delay" (when the delay was 4 hours).

The data: The AI consistently removed 60-80% of apologies from user drafts and replaced them with direct, confident language.

❌ "Sorry to bother you, but I was wondering if maybe 
    you could possibly share the report when you get a chance?"

✅ "Could you share the Q3 report by Thursday? 
    I need it for the client presentation Friday morning."

Research backs this up — a 2016 study found that apologies lose perceived sincerity with each repetition. One "sorry" registers as genuine. Four sounds like panic.

4. Specificity Is the Shortcut to Trust

The pattern: Vague emails ("Let's connect sometime") performed terribly compared to specific ones ("Could we do 15 minutes Thursday at 2pm to review the API spec?").

This applied everywhere:

Cold emails — "We help companies grow" vs. "We helped [Company X] reduce churn by 23%"
Follow-ups — "Just checking in" vs. "Following up on the proposal I sent Tuesday — any questions about the pricing in Section 3?"
Introductions — "I'd love to connect" vs. "I noticed your talk at ReactConf — your approach to state management mirrors a problem we just solved at [Company]"

The rule: If you can add a number, a date, a name, or a specific detail — do it. Every time.

5. End with a Binary Question

The pattern: Emails that ended with open-ended questions ("What do you think?" / "Let me know your thoughts") had weaker closing structures than emails ending with yes/no questions.

❌ "Let me know your thoughts on the proposal."
✅ "Does the $12,000 budget work, or should I scope a smaller pilot first?"

Binary questions get faster replies because they require less cognitive effort. The reader doesn't need to formulate an opinion — they just pick A or B.

The Meta-Lesson: Tone > Content

The biggest surprise from building this tool wasn't about what people wrote — it was about how they wrote it. The same message, restructured and re-toned, became a completely different email.

Most people know what they want to say. The problem is how they say it. That's the gap AI fills surprisingly well — not generating content from scratch, but reshaping your intent into professional, clear communication.

Try It Yourself

If you're curious, RewriteEmail.com is free to try — paste any email draft and see how AI restructures it. No sign-up required for the first rewrite.

The tool uses the patterns above (and many more) to transform drafts in about 30 seconds. It's been particularly useful for:

Non-native English speakers writing professional emails
Developers who need to communicate with non-technical stakeholders
Anyone who's ever stared at a draft for 20 minutes wondering "does this sound right?"

What email-writing patterns have you noticed in your own work? I'd love to hear in the comments.

How I Built a Free QR Code Generator That Runs 100% in Your Browser

Zihang Dong 董子航 — Thu, 09 Apr 2026 07:15:20 +0000

Last month I launched ToolKnit — a collection of 31 free browser-based tools. One of the latest additions is a QR Code Generator that supports URLs, text, Wi-Fi credentials, and email — all processed locally with zero server calls.

In this post, I'll walk through how I built it and share some interesting technical decisions along the way.

Why Another QR Code Generator?

Most QR code generators online either:

Require you to sign up
Add watermarks to the output
Upload your data to their servers
Limit the number of QR codes you can create

I wanted something that's completely free, private, and unlimited. Since everything runs in the browser using JavaScript, your data never leaves your device.

👉 Try it here: ToolKnit QR Code Generator

The Tech Stack

The tool is surprisingly simple:

HTML + Tailwind CSS for the UI
qrcode.js library for QR code generation (via CDN)
Canvas API for rendering and downloading

No React, no build tools, no backend. Just a single HTML file that works everywhere.

How QR Code Generation Works

QR codes encode data as a matrix of black and white squares. The qrcode.js library handles the heavy lifting:

const qr = new QRCode(document.getElementById('qr-output'), {
    text: inputText,
    width: 256,
    height: 256,
    colorDark: '#000000',
    colorLight: '#ffffff',
    correctLevel: QRCode.CorrectLevel.M
});

That's literally it for basic generation. But I wanted to support multiple content types, so I added a tab system for different QR code formats.

Supporting Wi-Fi QR Codes

This was the most interesting part. Did you know your phone can auto-connect to Wi-Fi by scanning a QR code? The format is:

WIFI:T:WPA;S:MyNetwork;P:MyPassword;;

Where:

T = Authentication type (WPA, WEP, or nopass)
S = SSID (network name)
P = Password

In my implementation:

function buildWifiString(ssid, password, encryption) {
    return `WIFI:T:${encryption};S:${ssid};P:${password};;`;
}

Super useful for cafes, offices, or events where you want guests to connect easily without typing long passwords.

Email QR Codes

Similarly, you can encode a mailto: link:

mailto:hello@example.com?subject=Hello&body=Hi there

When scanned, it opens the email app with pre-filled fields. Great for business cards or event badges.

Error Correction Levels

One thing I learned building this: QR codes have 4 error correction levels:

Level	Recovery	Best For
L (Low)	~7%	Clean digital screens
M (Medium)	~15%	General use (default)
Q (Quartile)	~25%	Printed materials
H (High)	~30%	Logos overlay, harsh conditions

Higher error correction means the QR code still works even if part of it is damaged or obscured. I defaulted to M (Medium) as a good balance between data density and reliability.

Custom Colors

I added color pickers for foreground and background colors:

const options = {
    colorDark: document.getElementById('fg-color').value,
    colorLight: document.getElementById('bg-color').value,
};

One gotcha: contrast matters. If someone picks similar colors for foreground and background, the QR code becomes unreadable. I considered adding a contrast check but decided to trust the user — most people intuitively pick high-contrast combinations.

Download as PNG

The qrcode.js library renders to a canvas element, so downloading is straightforward:

function downloadQR() {
    const canvas = document.querySelector('#qr-output canvas');
    const link = document.createElement('a');
    link.download = 'qrcode.png';
    link.href = canvas.toDataURL('image/png');
    link.click();
}

No server round-trip, no temporary file storage. The PNG is generated entirely in the browser.

SEO Considerations

Since ToolKnit is a tool site that relies on organic search traffic, I spent time on SEO:

Schema.org structured data — SoftwareApplication and FAQPage markup
5 FAQ questions with answers in JSON-LD
Semantic HTML — proper heading hierarchy, descriptive alt text
Performance — single-page tool with minimal dependencies loads fast

For tool sites, I've found that FAQ structured data is especially powerful. Google often shows FAQ rich snippets directly in search results, which dramatically improves click-through rates.

What I'd Improve

If I revisit this tool, I'd add:

SVG export for vector quality
Logo overlay in the center of the QR code (using H error correction)
Batch generation for creating multiple QR codes at once
vCard format for contact information

Try It Out

The QR Code Generator is live at toolknit.com/tools/qr-code-generator.html. It's one of 31 free tools on ToolKnit — all browser-based, no signup required.

Other popular tools on the site:

Character Counter — count characters, words & paragraphs
Image Compressor — compress images without quality loss
PDF to Word — convert PDFs to editable documents

If you're building browser-based tools, I'd love to hear about your approach. Drop a comment below! 🚀

Full tool list and source available on GitHub.

I Built 30+ Free Browser Tools in One Month — Here's What I Learned

Zihang Dong 董子航 — Wed, 08 Apr 2026 09:08:42 +0000

The Frustration That Started It All

It was a late night in March 2026. I needed to compress a PDF. Simple, right?

Nope. The first site hit me with a 30-second ad. The second wanted me to "download our free software" (spoiler: it wasn't free). The third uploaded my file to god-knows-where. I closed my laptop, stared at the ceiling, and thought:

"Why can't someone just build clean, fast tools that work in the browser?"

So I did. In one month, I built ToolKnit — a free, browser-based toolbox with 30+ tools. No uploads. No signups. No ads. Everything runs locally.

What I Built

Here's the full toolkit, organized by category:

📄 PDF Tools

Compress PDF — Shrink PDFs without losing quality
Merge PDF — Combine multiple PDFs into one
PDF to Word / Word to PDF
PDF to Image / Image to PDF

🖼️ Image Tools

Compress Image — Reduce file size in-browser
Image Crop — Crop with custom aspect ratios
Image Grid Split — Split images for Instagram carousels
Format converters: JPG↔PNG, JPG↔WebP, PNG↔WebP, WebP→JPG, WebP→PNG

🎬 Video & Audio

Compress Video — FFmpeg-powered, runs in browser via WASM
Video to GIF — Make GIFs from any video
MP3↔WAV converter

⏱️ Utilities

Stopwatch / Countdown Timer / World Clock
Character Counter — With social media limits built in
Extract Text — Pull text from PDF, DOCX, XLSX & 12+ formats
Keyboard Tester — Test every key on your keyboard

🎲 Fun Stuff

What to Eat? — A random food picker (yes, really)
Ask Fate — A Magic 8-Ball for life decisions
Spinner Wheel — Custom random picker
Reaction Time Test — How fast are your reflexes?
Drawing Board — Sketch, doodle & export

The Tech Stack

Nothing fancy. Intentionally simple:

HTML + Tailwind CSS — Static pages, no framework overhead
Vanilla JavaScript — No React, no Vue, just plain JS
FFmpeg.wasm — For video compression and GIF conversion in-browser
PDF.js + pdf-lib — For PDF manipulation without server uploads
Canvas API — For image processing (crop, convert, compress)
Web Workers — Heavy tasks don't block the UI

Every single operation happens in the user's browser. Files never leave the device. This was a non-negotiable design decision from day one.

Lessons Learned

1. Browser APIs are incredibly powerful now

You can compress video, manipulate PDFs, convert image formats, and process audio — all without a server. The gap between "browser tool" and "desktop app" is shrinking fast.

2. SEO is a full-time job

Building the tools was the easy part. Getting people to find them? That's where the real grind is. I spent as much time on meta tags, Schema.org markup, Open Graph images, sitemaps, and blog posts as I did on actual tool development.

3. PageSpeed matters more than you think

I obsessed over Lighthouse scores. Every tool page loads in under 1 second. No heavy frameworks. Lazy-loaded icons. Deferred scripts. The result? Google actually started indexing pages within days.

4. "Simple" tools still have edge cases

A "simple" JPG-to-PNG converter sounds trivial until you deal with EXIF orientation, color profiles, transparency handling, and batch downloads. Every tool had its own rabbit hole.

5. Fun tools drive traffic

My most popular pages? Not the PDF compressor. It's the Reaction Time Test and Keyboard Tester. People share fun tools. They bookmark utility tools.

What's Next

I'm planning to add:

Background remover (AI-powered, still client-side)
JSON/CSV formatter
Color palette generator
Markdown editor with live preview

If you have ideas for tools you wish existed, I'd love to hear them in the comments.

Try It Out

👉 toolknit.com — 30+ free browser tools, no signup, no uploads, 100% private.

If you find it useful, a bookmark or share would mean the world. I'm a solo developer building this after my 9-to-5, and every bit of support keeps me going. ✨

Built with ☕ and too many late nights by Mr.Dong

I Built a Free AI Sleep Tracker as a PWA — No App Store Needed

Zihang Dong 董子航 — Wed, 01 Apr 2026 16:16:03 +0000

The Problem

Most sleep tracking apps cost $30-60/year, require app store downloads, and upload your personal sleep data to the cloud. I wanted something simpler.

So I built OohSleep — a free Progressive Web App that tracks your sleep, detects snoring with AI, and helps you fall asleep with ambient sounds and breathing exercises.

What It Does

🎤 AI Snoring Detection — Uses the Web Audio API and MediaRecorder to listen for snoring patterns during sleep
🎵 8 Sleep Sounds — Rain, ocean waves, thunder, campfire, wind, forest stream, crickets, and snow — all mixable
🫁 5 Breathing Exercises — 4-7-8, Box Breathing, Belly Breathing, Alternate Nostril, and Physiological Sigh with guided animations
📊 Sleep Reports — Track duration, quality score, and sound events over time
📅 Sleep Calendar — Visual history with daily and weekly views

Tech Stack

No frameworks, no backend, no database. Just:

Vanilla HTML/CSS/JS
Web Audio API for sound mixing, playback, and audio analysis
MediaRecorder API for recording sleep audio and detecting snoring
Service Worker for full offline support
LocalStorage / IndexedDB for on-device data storage
PWA Manifest for cross-platform installation

Why PWA?

A Progressive Web App was the perfect fit:

Cross-platform — Works on iOS, Android, Windows, Mac
No app store — No review process, no 30% cut, instant updates
Offline first — Works without internet after first visit
Privacy by design — No server means no data collection

How Snoring Detection Works

The snoring detection uses the Web Audio API AnalyserNode to process microphone input in real-time. It captures audio via getUserMedia, runs FFT analysis to get frequency data, identifies characteristic snoring patterns (low-frequency rhythmic bursts), and uses MediaRecorder to save audio clips when snoring is detected.

Sound Mixing

Users can layer multiple ambient sounds simultaneously. Each sound has independent volume control through Web Audio API gain nodes, allowing custom sound environments for sleep.

Business Model

Free tier — Basic sleep tracking, timer, limited sounds, 7-day history
Premium $14.99/year — AI analysis, snoring detection, unlimited sounds, full history

Try It

👉 https://oohsleep.com

Open it on your phone, install it to your home screen, and try it tonight.

What technical challenges have you faced building PWAs? Let me know in the comments!