Forem: Zihang Dong 董子航

I Built 58 Free Browser Tools With Zero Backend — Here's the Full Stack

Zihang Dong 董子航 — Mon, 11 May 2026 04:53:17 +0000

Every "free online tool" site I've ever used follows the same playbook: upload your file to their server, wait, download the result — usually after a signup wall, a file-size cap, or a watermark slapped on your output. Your data sits on someone else's machine, and you just have to trust that they delete it.

I didn't love that. So I built ToolKnit — 58 free online tools that run entirely in your browser. No backend server. No file uploads. No accounts. No database. Just static HTML, CSS, JavaScript, and a pile of WebAssembly.

Here's how it all works under the hood.

The Architecture: There Is No Server

ToolKnit is a static site. Every page is plain HTML served from a single origin. There is no Express server, no Lambda function, no S3 bucket receiving your files. When you compress a PDF on ToolKnit, the compression happens on your device. When you convert a PNG to WebP, your browser's Canvas API does the pixel work. Nothing leaves your machine.

This isn't a philosophical choice — it's a technical one. Browser APIs in 2026 are powerful enough to handle 90% of what people use online tools for. The remaining 10% (think: server-side AI, heavy video transcoding at scale) doesn't justify compromising on privacy for the other 90%.

The Tech Stack

Layer	Technology
PDF	pdf-lib (WebAssembly) — compress, merge, split, convert
Video	FFmpeg.wasm — compress, convert to GIF, extract audio
Image	Canvas API + OffscreenCanvas — format conversion, crop, resize, compress, pixel art
Audio	Web Audio API + AudioContext — MP3 ↔ WAV conversion, video audio extraction
OCR	Tesseract.js — extract text from images
Crypto	Web Crypto API — password generation with true randomness
Export	Canvas 2D API — pixel-perfect PNG/PDF export for the Daily Planner
Styling	Tailwind CSS + Space Grotesk — consistent B&W theme across all 58 tools
Offline	Service Worker — full PWA, works without internet after first visit

No React. No Vue. No build step. Every tool is a self-contained HTML page with inline <script> tags. Sounds old-school? It is. It also means zero bundle size overhead, instant page loads, and the ability to cache every tool independently via the Service Worker.

58 Tools, 8 Categories

Here's what you can do without uploading a single byte to any server:

📄 PDF Tools (6)

Compress PDF, Merge PDF, PDF to Image, Image to PDF, PDF to Word, Word to PDF.

All powered by pdf-lib running in WebAssembly. The compression works by downsampling embedded images and stripping unused metadata — no quality loss on text, significant size reduction on image-heavy documents.

🖼️ Image Tools (12)

Compress, crop, resize, grid split, pixel art converter, flip & rotate, plus six format converters (JPG ↔ PNG ↔ WebP).

The pixel art converter is one of my favorites. It quantizes colors using median-cut, applies optional dithering (Floyd-Steinberg, ordered, Atkinson), and ships with presets for Game Boy, NES, and SNES palettes. All in ~400 lines of vanilla JS.

🎬 Video Tools (3)

Compress Video, Video to GIF, Video to Audio.

FFmpeg.wasm is a beast. It's a full FFmpeg compiled to WebAssembly — we're talking H.264 encoding/decoding, GIF muxing, and audio extraction, all in a browser tab. The trade-off is a ~25MB WASM download on first use, but it's cached by the Service Worker after that.

🎵 Audio Tools (2)

MP3 to WAV, WAV to MP3.

Web Audio API handles decoding. For MP3 encoding, we use a WASM-based LAME encoder. Bitrate is user-selectable from 128–320 kbps.

📝 Text Tools (6)

Character Counter, Lorem Ipsum Generator, Extract Text (OCR), QR Code Generator, Password Generator, Text Diff.

The Password Generator uses crypto.getRandomValues() — not Math.random(). Customizable length (4–128 chars), character type toggles, real-time strength analysis, and bulk generation up to 50 passwords at once.

Text Diff does line-by-line comparison with additions, deletions, and unchanged lines highlighted — unified or side-by-side view. Built from scratch, no difflib dependency.

🧮 Calculator Tools (4)

Age Calculator, Unit Converter, Percentage Calculator, BMI Calculator.

⏱️ Time & Productivity (6)

Stopwatch, Countdown Timer, World Clock, Pomodoro Timer, Invoice Generator, Timestamp Converter, Daily Planner.

The Daily Planner deserves its own section (see below).

🎮 Creative & Fun (13)

Whiteboard, Random Spinner Wheel, What to Eat?, Ask Fate (Magic 8-Ball), Keyboard Tester, Reaction Time Test, Aim Trainer, CPS Test, Coin Flip, Dice Roller, Color Picker, Gradient Generator, Daily Planner.

The Canvas 2D Rewrite: Why I Ditched html2canvas

The Daily Planner lets you design a weekly schedule and export it as a pixel-perfect PNG or PDF. Version 1 used html2canvas for the export. It worked — mostly. But html2canvas doesn't actually use your browser's rendering engine. It re-implements CSS in JavaScript, reads your DOM, and paints an approximation onto a canvas.

The result? Fonts were slightly off. Border-radius clips were wrong. Gradients didn't match. Every CSS property I added required checking whether html2canvas supported it.

So I ripped it out and wrote raw Canvas 2D API calls:

// Instead of html2canvas re-interpreting my CSS...
ctx.fillStyle = '#0a0a0a';
ctx.fillRect(0, 0, width, height);

ctx.font = '700 28px "Space Grotesk"';
ctx.fillStyle = '#ffffff';
ctx.fillText(title, x, y);

// Rounded rectangles for time slots
ctx.beginPath();
ctx.roundRect(slotX, slotY, slotW, slotH, 12);
ctx.fillStyle = 'rgba(255,255,255,0.04)';
ctx.fill();
ctx.strokeStyle = 'rgba(255,255,255,0.08)';
ctx.stroke();

Pixel-perfect. Zero offset. The export now matches the browser preview exactly. Sometimes the simplest solution is the one you should have picked first.

Privacy by Architecture

This isn't a privacy policy — it's a privacy architecture. There's no server to leak data because there's no server processing data. Your files are read by the browser's File API, processed in local memory, and the output is generated client-side. The only network requests ToolKnit makes are:

Google Analytics — page views only, no file data
Ahrefs Analytics — same, page views only
Google Fonts — loading Space Grotesk

That's it. No telemetry on what files you process, how large they are, or what tools you use. No cookies for tracking individual users. The only local storage is a daily usage counter (500 uses/day fair-use limit) and optional personal bests for gaming tools.

Offline-First: It's a PWA

ToolKnit registers a Service Worker that caches all tool pages and core assets on first visit. After that, you can:

Disconnect from the internet
Open any cached tool
Process files normally

On mobile, you can add ToolKnit to your home screen and it launches like a native app — full-screen, no browser chrome, instant load.

What I Learned Building This

Browser APIs are underrated. Canvas, Web Audio, File API, Crypto, Service Workers — you can build a lot before you need a server.
WebAssembly is production-ready. pdf-lib and FFmpeg.wasm handle real workloads. The WASM download is the only downside, and caching solves it.
Static sites scale infinitely. No server means no server costs, no server crashes, no server maintenance. The only cost is the domain and CDN.
Privacy sells itself. I never marketed ToolKnit as a "privacy tool." But when users realize their files never leave their device, they tell other people. Word of mouth from trust is the best marketing channel.
One tool at a time. I built and shipped one tool per session, tested it live, then moved on. 58 tools later, the compound effect is real.

Try It

toolknit.com — 58 free tools, zero uploads, works offline.

If ToolKnit has ever saved you five minutes, or helped you avoid installing yet another sketchy desktop app — share it with someone. Drop it in a Reddit thread. Mention it to a colleague. Every recommendation means the world to a solo developer shipping code at midnight.

Built by Zihang Dong. Follow the journey on GitHub.

I just shipped my 50th free browser tool — here's what building alone at midnight looks like

Zihang Dong 董子航 — Fri, 08 May 2026 16:50:26 +0000

It's 12:30 AM. The apartment is quiet. The only light is my monitor, and the terminal cursor blinks like a heartbeat.

Tonight, ToolKnit crossed 50 tools. Fifty-two, to be exact.

What is ToolKnit?
ToolKnit is a collection of free, browser-based tools — PDF converters, image editors, video compressors, text utilities, calculators, and more. Every tool runs entirely in your browser. No file uploads, no sign-ups, no server-side processing. Your files never leave your device.

The stack is deliberately simple: static HTML, Tailwind CSS, vanilla JavaScript. No React, no Next.js, no build step. Just files on a server.

What shipped tonight
Three new tools and a brand new category:

Unit Converter — 8 categories (length, weight, temperature, area, volume, speed, data, time), bidirectional conversion with real-time results
Percentage Calculator — three modes: "X% of Y", percentage change, and "X is what % of Y"
Markdown Editor — side-by-side live preview, export to .md, copy rendered HTML, word/char/line stats
These three, along with the existing Age Calculator, formed a new Calculator Tools category — the 8th category on the platform.

The unglamorous parts
Building solo means you're the developer, the designer, the QA team, the DevOps engineer, and the person who accidentally deploys the wrong file to production at 11 PM.

The Encoding Incident
I discovered that 46 out of 52 tool pages had garbled characters. Every em-dash had been corrupted into �? — the Unicode replacement character. Somewhere in a batch edit, UTF-8 encoding broke silently across nearly the entire site.

46 files. One silent bug. Encoding is the villain arc nobody warns you about.

The Homepage Incident
While deploying fixes, I accidentally SCP'd blog/index.html to the root directory — overwriting the entire homepage with the blog page. The main landing page, just gone.

Caught it within a minute. Fixed it in two. But that's the kind of mistake that makes your stomach drop when you're the only person between "working website" and "oops."

By the numbers
Metric Count
Total tools 52
Blog articles 51
Tool categories 8
Files with encoding bugs fixed tonight 46
Times I accidentally broke production 1
Time to fix it ~60 seconds
Why build this way?
I get asked why I don't use a framework. Why no React, no component library, no CMS.

The answer is simple: every tool is a single HTML file. No build step means no build failures. No dependencies means no supply chain risk. No server processing means no server costs beyond a basic VPS. A user opens a page, the tool works. That's it.

The trade-off is that updates require touching many files manually. Tonight I had to update the tool count in index.html, manifest.json, 404.html, changelog.html, service-worker.js, sitemap.xml, search.js, and the var tools array inside all 52 tool pages. That's the price of simplicity.

What's next
More tools. Same chair, same dark room, same quiet conviction that free tools should just work.

If you want to check it out: toolknit.com

If you're also building something alone at midnight — I see you.

— Zihang Dong, May 9, 2026

Why AI Image Generators Are Moving From "One Prompt Box" to Specialized Workflows

Zihang Dong 董子航 — Sun, 03 May 2026 09:31:34 +0000

Why AI Image Generators Are Moving From "One Prompt Box" to Specialized Workflows

The Era of the Generic Prompt Box Is Ending

In 2023, every AI image generator looked the same: a text box, a generate button, and a prayer.

By 2026, the market has split. On one side, you have the incumbents — Midjourney, DALL-E, Stable Diffusion — competing on raw model quality. On the other side, a new wave of tools is emerging that focuses not on the model, but on the workflow.

This shift matters for builders, designers, and anyone betting on the AI creative tools market.

The Problem With General-Purpose AI Image Tools

General-purpose tools optimize for flexibility. You can generate anything — landscapes, portraits, logos, abstract art — with the right prompt.

But flexibility comes at a cost:

1. The Prompt Engineering Tax

To get good results from a general-purpose tool, you need to learn prompt engineering. "A cat" gives you a mediocre cat. "A photorealistic orange tabby cat sitting on a rustic wooden windowsill, golden hour lighting, shallow depth of field, shot on Canon EOS R5" gives you a great cat.

Most users don't want to become prompt engineers. They want a great cat.

2. The Context Switching Problem

If I want to convert a photo to anime style, I don't want to write a prompt. I want to upload a photo and pick a style. If I want to design a tattoo, I don't want to guess which keywords produce clean line art on white backgrounds. I want to select "minimalist" from a dropdown.

General-purpose tools force users to translate their intent into prompt language. Specialized tools eliminate that translation step.

3. The Output Format Problem

A sticker needs a white background and clean edges. A wallpaper needs specific aspect ratios. A profile photo needs face-centric composition. General-purpose tools don't enforce these constraints — users have to figure them out through trial and error (and wasted credits).

The Specialized Workflow Approach

The alternative is building separate interfaces for separate use cases, each with its own:

Pre-built prompt templates
Style presets relevant to that specific use case
Output constraints (aspect ratio, background, composition)
UI optimized for that workflow (file upload for image-to-image, style picker for design tools)

This is the approach behind tools like 24picture, which offers distinct workflows for text-to-image, photo-to-anime, tattoo design, sticker creation, upscaling, and photo restoration — each with its own optimized interface.

Why This Matters for the Market

1. Lower Barrier to Entry

When you remove prompt engineering from the equation, you open the market to non-technical users. A tattoo artist exploring design concepts doesn't need to learn AI terminology — they pick a style and describe what they want in plain language.

2. Higher Conversion Rates

Specialized landing pages for specific use cases (like "AI cyberpunk art generator") convert significantly better than generic "AI image generator" pages. Users searching for specific solutions have higher intent.

3. Defensible Differentiation

Raw model quality is becoming commoditized. GPT-Image, Flux, Midjourney — they all produce impressive results. The differentiation is moving upstream to the workflow layer: how easy is it to get from intent to result?

4. Better Unit Economics

Credit-based pricing aligned to specific workflows enables better pricing. A quick sticker generation can cost less than a complex 4K upscale. This granularity isn't possible with flat subscription models.

What Builders Should Take Away

If you're building in the AI image space, consider:

Don't compete on model quality — you'll lose to the incumbents with billion-dollar training budgets
Compete on workflow design — the gap between "technically possible" and "easy to do" is where value lives
Build for specific use cases — "AI tattoo design tool" is a more winnable position than "AI image generator"
Let users skip the prompt — preset templates, style selectors, and smart defaults beat empty text boxes

The winners in AI creative tools won't be the ones with the best models. They'll be the ones who make the best models accessible to people who don't care about models.

AI Image Generation Workflows Beyond Text-to-Image

Zihang Dong 董子航 — Sun, 03 May 2026 09:30:46 +0000

5 AI Image Generation Workflows Beyond Text-to-Image

Everyone talks about text-to-image AI. You type a prompt, you get a picture. Cool.

But the real utility of AI image generation goes way beyond typing prompts into a box. Here are 5 workflows that are genuinely useful in 2026 — and how they actually work under the hood.

1. Photo to Anime Conversion

What it does: Upload a regular photo, get back an anime/manga-style version of the same image.

Why it's useful: Social media avatars, profile pictures, gifts. People love seeing themselves in anime style without hiring an artist.

How it works technically:

The input image is processed through an image-to-image model that applies style transfer while preserving the subject's key features — face shape, expression, pose. The trick is controlling how much of the original is preserved vs. how much is stylized.

On 24picture, users can choose from 6 anime styles ranging from subtle to heavy stylization. Each style maps to a different prompt template that controls the transformation intensity.

2. AI Upscaling (Image Enhancement)

What it does: Takes a low-resolution image and outputs a high-resolution version with added detail.

Why it's useful: Old photos, screenshots, thumbnails that need to be printed — any image that's too small for its intended use.

How it works technically:

Modern upscaling models don't just interpolate pixels (like bicubic upscaling). They use trained neural networks that predict what the missing detail should look like based on the existing content. A face in a blurry photo gets sharper features because the model has learned what faces look like at high resolution.

The quality difference between AI upscaling and traditional upscaling is dramatic — especially at 4x magnification.

3. AI Tattoo Design

What it does: Generate tattoo concepts from text descriptions, with style presets like traditional, minimalist, geometric, watercolor, etc.

Why it's useful: Tattoos are permanent. Being able to explore dozens of variations before committing saves both money and regret.

How it works technically:

This is text-to-image with heavy prompt engineering. Each style preset injects specific instructions:

"Traditional" adds: bold outlines, limited color palette, American traditional style
"Minimalist" adds: thin single-line drawing, minimal shading, white background
"Geometric" adds: geometric shapes, symmetrical patterns, sacred geometry

The white/transparent background is forced to make it easy to visualize the design on skin.

4. Photo Restoration & Colorization

What it does: Fixes damage in old photos (scratches, tears, fading) and adds realistic color to black-and-white images.

Why it's useful: Family photos from decades ago can be brought back to life. This was previously a $50-100 professional service.

How it works technically:

Two-step pipeline:

Restoration: An inpainting model identifies damaged areas and reconstructs them based on surrounding context
Colorization: A separate model predicts historically accurate colors based on the objects, clothing, and setting in the image

The colorization step is particularly impressive with modern models — they can correctly color military uniforms, vintage cars, and natural landscapes based on era-appropriate references in their training data.

5. AI Sticker Generation

What it does: Creates custom sticker designs with clean edges and white backgrounds, ready for printing or digital use.

Why it's useful: Custom stickers for messaging apps, product packaging, event branding — all without a graphic designer.

How it works technically:

The key challenge is clean edges. Regular text-to-image models produce images with complex backgrounds that don't work as stickers. The solution is forcing a white background in the prompt and using a model that handles flat illustration styles well.

24picture's sticker maker forces these constraints automatically so users just describe what they want without worrying about technical details.

The Bigger Picture

Text-to-image gets all the hype, but these specialized workflows are where AI image generation becomes genuinely practical. They solve specific problems that people actually pay for.

If you want to try any of these workflows: 24picture.com offers all five with a free trial (50 credits on signup, no credit card required).

The future of AI image tools isn't one giant prompt box — it's purpose-built workflows for specific creative tasks.

How I Built an AI Image Generator That Actually Works in 2026

Zihang Dong 董子航 — Sun, 03 May 2026 09:29:00 +0000

The AI image generation space has exploded. Everyone and their grandma has an "AI art generator" now. Most of them are just wrappers around the same API with a different color scheme.

I wanted to build something different — a tool that actually solves real problems for real people, not just another prompt box.

This is how I built 24picture, and what I learned along the way.

The Problem With Most AI Image Tools

Most AI image generators follow the same formula:

Text box for your prompt
A "Generate" button
Wait 30 seconds
Get something that looks vaguely like what you asked for

The issues:

No guidance — beginners have no idea how to write good prompts
One trick pony — they only do text-to-image, nothing else
Expensive — $20/month for 100 generations? No thanks
Slow — 30-60 seconds per image is painful

What I Built Instead

24picture tackles all four problems:

1. AI-Powered Prompt Assistance

Instead of leaving users to figure out prompt engineering, I integrated an AI polish feature. You type a rough idea like "cat on a roof" and the system rewrites it into a detailed, high-quality prompt that actually produces great results.

2. Multiple Creative Workflows

Text-to-image is just one feature. The platform also supports:

Photo to Anime — upload a photo, get an anime version
AI Upscaling — enhance low-resolution images to 4K
AI Stickers — generate custom sticker designs
AI Tattoo Design — explore tattoo concepts before committing to ink
Photo Restoration — fix and colorize old photos

Each workflow has its own optimized interface instead of cramming everything into one generic prompt box.

3. Credit-Based Pricing

No subscriptions. You buy credits, you use credits. Starting at $1.99 for 300 credits. One standard generation costs about 10 credits, so that's 30 images for less than $2.

4. Speed

Most generations complete in under 15 seconds. The key is choosing the right model for each use case instead of routing everything through the same pipeline.

Technical Architecture (High Level)

The stack is intentionally simple:

Frontend: Vanilla HTML/CSS/JS — no framework overhead
Backend: PHP 8.4 + MySQL 8.4
Server: Nginx on a single VPS
AI Models: Multiple providers, routed per feature
Auth: Magic link (passwordless email login)

Why no React/Next.js? Because for a tool like this, the added complexity doesn't justify itself. The pages load in under 1 second. The UX is smooth. SEO works out of the box because every page is plain HTML.

What I Learned

Lesson 1: Prompt Templates Beat Prompt Boxes

For specialized tools like tattoo design or sticker generation, pre-built prompt templates with user-selectable styles convert 3x better than empty text boxes.

Users don't want to learn prompt engineering. They want results.

Lesson 2: Credits > Subscriptions for New Products

When you're unknown, asking for $20/month is a huge trust barrier. Credits let people try the product for $2 and come back when they're convinced.

Lesson 3: SEO Still Works for AI Tools

Despite the "AI search is killing SEO" narrative, programmatic landing pages for specific use cases (like "AI Cyberpunk Generator") still drive real organic traffic. The key is matching search intent exactly.

Lesson 4: Ship the Ugly Version First

My first version looked terrible. But it worked. And that's what mattered. I spent 2 weeks on functionality before touching CSS. Best decision I made.

What's Next

More specialized generators (avatar, wallpaper, headshot)
Batch generation for power users
API access for developers
Community gallery

If you want to try it out: 24picture.com — new users get 50 free credits, no credit card needed.

Questions?

Drop a comment below if you're building something similar or have questions about the architecture. Happy to share more details.

We shipped an AI Cyberpunk Generator for 24picture

Zihang Dong 董子航 — Fri, 01 May 2026 07:16:59 +0000

Today we shipped a new landing page for 24picture: an AI Cyberpunk Generator.

Link:
https://24picture.com/ai-cyberpunk-generator.html

The goal was simple: keep building SEO-focused use-case pages around high-intent image generation queries, while making sure each page is still genuinely useful to users.

Instead of publishing a thin “keyword page”, we built a full landing page with:

a clear product-focused headline
prompt examples for cyberpunk scenes
use cases like wallpapers, thumbnails, album covers, and concept art
FAQ schema for richer search visibility
internal links from the homepage, create page, and core generator page
sitemap updates for faster discovery

The keyword angle here is AI cyberpunk generator, but the real intent behind it is broader:
people want to generate neon cityscapes, android portraits, rainy dystopian streets, cyberpunk anime, and futuristic wallpaper-style visuals without needing Photoshop or 3D tools.

So the page was written to serve both:

search engines
real users looking for inspiration and prompts

A few things I’m learning while building 24picture in public:

1. Programmatic SEO works better when the page is actually helpful

It’s easy to mass-produce pages with swapped keywords.

It’s much harder — and much more worthwhile — to create pages that genuinely help someone get a better result.

For this one, that meant including prompt structure, style keywords, and realistic use cases instead of just repeating the target phrase.

2. Internal linking matters more than people think

We didn’t just publish the page and leave it isolated.

We also linked it from:

the homepage footer
the create page
the main text-to-image page
the sitemap

That gives both users and crawlers a better path to find it.

3. Shipping small pages consistently is better than waiting for “perfect”

This wasn’t a massive feature launch.

It was one focused page, shipped fast, tied to a clear keyword and a clear user intent.

That’s the kind of compounding work we’re trying to do with 24picture.

Next up: more landing pages, more comparison pages, and more experiments around AI image search intent.

If you’re also building SEO pages for an indie product, I’d love to hear how you balance search intent vs actual usefulness.

How I Built an AI Image Studio with 9 Tools Using PHP 8.4 — Architecture, Bugs & Lessons

Zihang Dong 董子航 — Wed, 29 Apr 2026 09:17:57 +0000

I just launched 24picture — an all-in-one AI image studio with 9 specialized tools. Built with PHP 8.4, MySQL 8.4, and Nginx.

In this post I'll share the architecture decisions, the nastiest bug I encountered, and what I learned shipping a real AI product.

What I Built

Instead of yet another "text to image" wrapper, I built a platform with 9 tools:

Text to Image — 3 AI models, up to 4K resolution
Image to Image — transform existing photos
AI Upscale — enhance images up to 4K
AI Model — virtual model photography
AI Tattoo Design — custom flash sheets in 7 tattoo styles
AI Sticker Maker — die-cut stickers from text prompts
Photo to Anime — turn photos into anime art
AI Photo Notes — stylized photo annotations
AI Polish — one-click prompt enhancement via DeepSeek API

All tools share the same backend — one create.php to submit jobs, one status.php to poll results. The frontend does prompt template assembly per tool.

Tech Stack

Layer	Tech
Backend	PHP 8.4 (no framework)
Database	MySQL 8.4
Web Server	Nginx
CDN / Security	Cloudflare
AI Models	Nano Banana 2, NB Pro, GPT Image (via kie.ai API)
Prompt Enhancement	DeepSeek API
Email	Resend API (magic link auth)
Payments	Creem (credit-based, no subscription)

Why PHP with No Framework?

Controversial take: for an API-centric product with ~15 endpoints, a framework adds more complexity than it solves. Raw PHP 8.4 with PDO, strict typing, and a single config.php bootstrap keeps things dead simple. The entire backend is about 2,000 lines of code.

Architecture: One Backend, Nine Tools

The key design decision was making all 9 tools share the same backend pipeline:

Frontend (per-tool UI)
  → assembles prompt from user inputs
  → POST /api/generate/create.php
    → deduct credits
    → call AI API
    → save generation record
  → poll GET /api/generate/status.php
    → check AI API status
    → on success: save result, create thumbnail, send email
    → return result to frontend

Adding a new tool means creating a new HTML page that assembles a different prompt template. Zero backend changes. I went from 3 tools to 9 in a single day using this pattern.

The Nastiest Bug: 4K Thumbnails Crashing PHP

This one took me a while to figure out. Users would generate a 4K image successfully, but the status endpoint would return a 500 error — every single time. The image was ready on the AI provider's side, but our server kept crashing when trying to process it.

The Problem

When a generation completes, status.php creates a thumbnail using PHP's GD library:

$src = imagecreatefromstring($imgData);

For a 4K image (roughly 4096 × 2304 pixels), GD needs to hold the uncompressed bitmap in memory:

4096 × 2304 × 4 bytes (RGBA) × 2.5 (overhead) ≈ 94 MB

PHP's default memory limit is 128MB. With the rest of the script's memory usage, this pushed it over the edge. The fatal memory error killed the script before the database was updated, so the next poll attempt would try the same thing — an infinite crash loop.

The Fix

Three changes:

1. Update the database FIRST, before attempting the thumbnail:

// Mark as success immediately
$stmt = $db->prepare('UPDATE generations SET status = "success", 
    result_url = ?, completed_at = NOW() WHERE task_id = ?');
$stmt->execute([$resultUrl, $taskId]);

// THEN try thumbnail (best-effort)
try {
    $thumbUrl = createThumbnail($resultUrl, $gen['id']);
} catch (\Throwable $e) {
    error_log("Thumbnail failed: " . $e->getMessage());
}

Even if the thumbnail crashes, the next poll returns cached success.

2. Memory estimation before loading the image:

$info = getimagesizefromstring($imgData);
$needed = $info[0] * $info[1] * ($info['channels'] ?? 4) 
          * ($info['bits'] ?? 8) / 8 * 2.5;
if ($needed > 128 * 1024 * 1024) {
    return null; // skip thumbnail for huge images
}
ini_set('memory_limit', '256M');

3. Wrap everything after the DB update in try-catch so no post-processing error can block the response.

Lesson Learned

Always persist your state change before doing expensive side effects. If your script can crash during step N, make sure steps 1 through N-1 are already committed.

This applies to any pipeline: payment processing, webhook handling, email sending — commit the critical state first.

Credit System Design

I chose pay-as-you-go credits instead of subscriptions:

Model	1K	2K	4K
Nano Banana 2	10	15	24
NB Pro	24	24	30
GPT Image	8	13	20

Credits never expire. Free credits on signup. This removes the "am I getting my money's worth?" anxiety that subscriptions create.

For the backend, credit deduction uses a simple SELECT ... FOR UPDATE lock to prevent race conditions:

$db->beginTransaction();
$stmt = $db->prepare('SELECT credits FROM users WHERE id = ? FOR UPDATE');
$stmt->execute([$userId]);
$credits = (int)$stmt->fetchColumn();

if ($credits < $cost) {
    $db->rollBack();
    return error('Insufficient credits');
}

$stmt = $db->prepare('UPDATE users SET credits = credits - ? WHERE id = ?');
$stmt->execute([$cost, $userId]);
$db->commit();

Important: release the lock before calling the external AI API. Don't hold database locks across network calls.

Security Checklist (Things I Almost Forgot)

A quick list for anyone shipping a similar product:

✅ Session cookies: HttpOnly, Secure, SameSite=Lax
✅ File upload validation: getimagesize() server-side, not just MIME
✅ Download proxy: whitelist allowed domains to prevent SSRF
✅ Rate limiting on contact forms (IP-based)
✅ XSS escaping on all user-generated content in the frontend
✅ SQL injection prevention: parameterized queries everywhere
✅ Feature whitelist: validate feature parameter against allowed values

What's Next

The product is live at 24picture.com. Currently focused on:

Growing organic traffic through SEO and content
Adding more specialized tools (AI Interior Design, AI Product Photo)
Building a Chrome extension for right-click AI upscale

If you're building something similar, I hope this post saves you from the 4K thumbnail crash and the database lock pitfall. Happy to answer questions in the comments!

If you want to try it out, there are free credits on signup — no card required: 24picture.com

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