Forem: tommy

I Built a Skitch Alternative 2 Months Ago. It Now Has Twice the Tools.

tommy — Sat, 04 Apr 2026 23:53:58 +0000

There's no pen tool.

I found a bug, took a screenshot with my own tool, drew an arrow, placed some text. So far so good. But I wanted to circle this curved area freehand. I looked for a pen tool. It wasn't there.

I made this thing. And it doesn't have what I need.

Two months ago, I wrote about building a Skitch alternative in one day. That version had 5 tools: arrow, text, rectangle, mosaic, and numbered circles. "This is enough," I thought.

It wasn't. Using it every day revealed what was missing.

This is the story of growing from 5 tools to 9.

PureMark Annotate — Opens in your browser. No install, no login, nothing leaves your device.
annotate.puremark.app

What I Added

Tool	Why I Needed It
Pen (freehand)	Rectangles can't outline curved shapes
Marker (highlight)	Needed semi-transparent emphasis without hiding text
Straight line	Less assertive than arrows for "from here to here"
Ellipse	Rectangles look awkward around non-rectangular targets

Beyond tools, I fixed friction points I discovered through daily use:

Feature	Before	After
Undo	None	50-step history stack
Stroke size	Fixed	S / M / L
Text size	Fixed (24px)	S(18) / M(24) / L(36)
Export	3x scale + PNG	1x + JPEG 0.92

What Google Search Console Taught Me

I was checking GSC data when something caught my eye.

Annotate's impressions spiked one week. +450%. The search queries: "screenshot annotation tool free", "add arrow to screenshot", "image markup online".

These weren't developers.

I'd assumed my tool was for developers because I'm a developer. But GSC said otherwise. People who annotate screenshots aren't just engineers — they're PMs filing bug reports, IT staff writing manuals, directors giving design feedback.

That's when I pivoted. I changed meta descriptions to Japanese (85% of users were from Japan, but descriptions were in English). I changed applicationCategory from DeveloperApplication to MultimediaApplication. Added JSON-LD structured data. Basic stuff I'd completely overlooked.

iPhone Images Went from 5MB to 800KB

One day I saved an annotated image on my iPhone. 5.2MB. Too heavy to paste into chat.

The culprit was 3x export scaling. I'd been exporting at triple resolution for Retina sharpness, but 1x was perfectly fine in practice. Switching from PNG to JPEG (quality: 0.92) sealed the deal.

// Before: 3x PNG — 5.2MB
const scale = 3;
canvas.toBlob(blob => { /* ... */ }, 'image/png');

// After: 1x JPEG — 0.8MB
const scale = 1;
canvas.toBlob(blob => { /* ... */ }, 'image/jpeg', 0.92);

85% reduction in file size. The quality difference? You'd have to put them side by side to notice.

Users don't want "beautiful images." They want images they can send right now.

Works great on mobile too. iPhone, Android — just a browser.
annotate.puremark.app

Android Camera OOM'd

Testing on a Redmi 12 5G (4GB RAM), I took a photo and switched back to the browser. White screen. OOM — out of memory.

Using capture="environment" triggers the system camera, which generates 12-50 megapixel images. The browser tries to decode at full size and crashes before reaching any resize logic.

The fix: implement an in-app camera with getUserMedia and cap resolution at 1920x1440.

const stream = await navigator.mediaDevices.getUserMedia({
  video: {
    facingMode: 'environment',
    width: { max: 1920 },
    height: { max: 1440 },
  }
});

But that alone didn't work. My Cloudflare _headers had Permissions-Policy: camera=() — blocking camera API for all origins. The browser silently denied access without even showing a permission dialog. Changed to camera=(self) and it worked.

Security headers protect you when configured correctly. When they're not, they become invisible bugs.

Undo Almost Killed It

Adding drawing tools meant I needed Undo. You draw a pen stroke, realize it's wrong, and want to go back.

I wrote about the implementation details in a separate article. The short version: Canvas API has no concept of "remove an element" like the DOM. Every undo clears the canvas and redraws all annotations from scratch. 50-step history stack — undo removes the last item and redraws, redo adds it back.

Sounds simple, but mosaic has a different draw order (it reads pixels from the original image), so rendering splits into 3 passes: Pass 1: Mosaic, Pass 2: Highlights, Pass 3: Everything else. Get the order wrong and mosaic overlaps your annotations.

2 Months in Numbers

Metric	February (launch)	April (now)
Tools	5	9
MAU	0	328
Zenn articles	1	17
Chrome extension installs	—	52
GSC impressions (Annotate)	0	peak 80/week

MAU is 328. The Gate 1 target is 500 — I'm at 65%. Still a ways to go, but the tool feels like something I want to use now.

Cross-tool navigation rate (users who visit other PureMark tools) exceeded 20%. One in five people use the full suite, not just Annotate. That was a good number to see.

Beyond "There's No Pen"

Two months ago, I noticed there was no pen. Today, there is. And a marker, and ellipses, and Undo.

But I'll notice something else missing soon. Because I'm still the primary user.

The best part of building your own tool is that the distance from "this is missing" to "done" is zero. No tickets, no sprint planning. You notice it and you ship it. That's how 5 became 9. I don't know what 9 becomes next.

A tool that started with "just draw an arrow on a screenshot" isn't just about arrows anymore.
PureMark Annotate — Try it now in your browser

References

I Added 5 Drawing Tools to My Canvas App. Undo Almost Killed It.

tommy — Sat, 21 Mar 2026 22:34:17 +0000

The best part of building your own tools is that you can add whatever you want.

I was filing a bug report and opened my own annotation tool to mark up a screenshot. I drew an arrow. But I wanted a freehand pen to circle the area. No pen. I tried a rectangle — the thing I was highlighting wasn't rectangular. I wanted an ellipse. No ellipse either.

I built this thing. And it was frustrating me.

——So I added them. Today.

This is the story of a major update to PureMark Annotate — a browser-based screenshot annotation tool (no install, no login). I started with 5 tools: arrow, text, rectangle, numbered circle, and mosaic. I added freehand pen, marker/highlight, straight line, ellipse, and Undo/Redo all at once.

PureMark Annotate — Works in your browser. No install, no account.
👉 annotate.puremark.app

"Just adding tools to Canvas" sounded simple. There were 3 real gotchas. And they were fun.

The Pen Was Jagged

The first implementation was straightforward. Collect coordinates in a points array on every mousemove, connect them with lineTo.

ctx.beginPath();
ctx.moveTo(pts[0].x, pts[0].y);
for (let i = 1; i < pts.length; i++) {
  ctx.lineTo(pts[i].x, pts[i].y);
}
ctx.stroke();

Slow strokes looked fine. Fast strokes looked like a bar chart.

mousemove doesn't fire continuously — it fires at intervals. Move fast and the gap between events gets large. You connect those distant points with a single straight line. That's your jagged pen.

Fix: Quadratic Bézier curves through midpoints

Use the midpoint between adjacent points as the curve's endpoint, and the previous point as the control point. This interpolates a smooth curve between the raw coordinates.

ctx.beginPath();
ctx.moveTo(pts[0].x, pts[0].y);

for (let i = 1; i < pts.length - 1; i++) {
  const mid = {
    x: (pts[i].x + pts[i + 1].x) / 2,
    y: (pts[i].y + pts[i + 1].y) / 2,
  };
  ctx.quadraticCurveTo(pts[i].x, pts[i].y, mid.x, mid.y);
}
const last = pts[pts.length - 1];
ctx.lineTo(last.x, last.y);
ctx.stroke();

The moment I tested it, the line went smooth. I literally said "oh nice" out loud. A few lines of change, and fast strokes turned into proper curves. These little discoveries are what make indie dev fun.

The Marker Got Darker When Overlapped

The highlight/marker tool should've been simple: globalAlpha = 0.35, then fillRect. Done.

But when I put an arrow on top of a highlighted area, the alpha values composed and the highlight got darker. Two overlapping highlights did the same. Something felt off.

Fix: 3-pass rendering

Every frame I clear the Canvas and redraw all annotations from scratch. I locked in this drawing order:

Pass 1: Mosaics — must read from the original image first
Pass 2: Highlights — rendered below everything else
Pass 3: Everything else — arrows, text, rectangles, pen strokes

for (const a of all) {
  if (a.type === 'Mosaic') drawMosaic(ctx, a, imageCanvas);
}
for (const a of all) {
  if (a.type === 'Highlight') drawHighlight(ctx, a);
}
for (const a of all) {
  if (a.type !== 'Mosaic' && a.type !== 'Highlight') drawAnnotation(ctx, a);
}

Now highlights are always drawn exactly once per frame, so the opacity stays consistent. As a bonus, this "clear and redraw everything" approach turned out to be perfect for Undo/Redo too.

Undo Almost Killed the Tab

This one was the most interesting.

My first instinct: use ctx.getImageData() to snapshot the whole Canvas on every stroke, and push it onto a history array. Simple, intuitive. I built it and ran it.

After about 5 strokes, the Chrome tab silently died. No error. Just gone.

The math made it obvious:

Item	Value
Typical iPhone photo	4000 × 3000 px
Data per pixel	4 bytes (RGBA)
One snapshot	4000 × 3000 × 4 = ~46 MB
50 steps of history	46 MB × 50 = ~2.3 GB

Of course it crashed.

I sat with it for a bit. Then it clicked: I'm trying to save what the Canvas looks like. But what I actually need to save is what's drawn on it.

The pixel data is just a rendering output. The real data is the annotations themselves — coordinates, color, type, stroke width. Pure JavaScript objects, a few dozen bytes each.

Fix: history + future stacks of annotation arrays

const MAX_HISTORY = 50;

// on finalize (stroke complete)
set({
  history: [...history.slice(-(MAX_HISTORY - 1)), annotations],
  future: [],
  annotations: [...annotations, currentAnnotation],
});

// undo
const prev = history[history.length - 1];
set({
  future: [...future, annotations],
  history: history.slice(0, -1),
  annotations: prev,
});

// redo
const next = future[future.length - 1];
set({
  history: [...history, annotations],
  future: future.slice(0, -1),
  annotations: next,
});

50 steps of history. Memory cost: a few KB. Ctrl+Z goes back one step. Ctrl+Y goes forward. The obvious thing works obviously.

When it clicked into place, I made a noise.

When getImageData snapshots make sense:
If you need to undo pixel-level changes (like painting or blurring), you do need imageData. But for annotation tools where you're only adding and removing objects, storing the data array is all you need.

Before / After

	Before	After
Drawing tools	arrow, text, rect, counter, mosaic	+ pen, marker, line, ellipse
Undo	none	50 steps
Memory for history	—	a few KB

PureMark Annotate — Open it, paste a screenshot, annotate. Nothing to install.
👉 annotate.puremark.app

Now I can take a bug report screenshot, circle the problem with a pen, and hit Ctrl+Z if I mess up.

The thing I wanted to exist, exists. I made it. That moment — where the tool you built does exactly what you needed — is probably my favorite part of building things for yourself.

References

The Day Skitch Stopped Working — Which Screenshot Annotation Tool Should You Use in 2026?

tommy — Thu, 19 Mar 2026 11:04:09 +0000

I tried to annotate a bug report screenshot, like I do every morning.

Skitch wouldn't launch.

It was the day after I updated to macOS Tahoe. Nothing but a crash log. That familiar green icon — gone.

It's 2026 now. Skitch's development effectively stopped in 2016. The Windows, iOS, and Android versions were officially discontinued back in January 2016. Only the Mac version kept working by some miracle. That miracle just ended.

PureMark Annotate is a free image annotation tool that works right in your browser. No installation, no account required. For those who loved Skitch's simplicity.

A Decade of "Just Adding Arrows" — Gone

What made Skitch great was that it didn't try to do too much.

Take a screenshot. Add an arrow. Drop some text. Apply a mosaic blur. Done. Ten seconds from launch to finish. Daily bug reports, documentation images, diagrams for Slack — all Skitch.

And now it won't open. Time to find a replacement. The first thing I saw was Snagit.

I Couldn't Justify $39/Year for Snagit

Snagit is the king of screenshot tools. Feature-wise, no complaints. But on February 12, 2025, TechSmith killed the perpetual license and switched to a $39/year subscription.

$39 a year to add arrows.

Reddit and Hacker News were full of users upset about what felt like a bait-and-switch — paying for something that used to be a one-time purchase. I get it. I closed that tab too.

I Spent a Week Trying Every Alternative

Here's what happened. I tried them all over the course of a week.

CleanShot X ($29 one-time / macOS only)

Honestly, the features are excellent. Scrolling capture, OCR, cloud sharing — it does everything.

But it's macOS only. $29 one-time with one year of updates, then $19/year for continued updates. Great on my personal Mac, useless on my work Windows machine.

Shottr (Free / macOS only)

Light. Fast. Beautifully designed — Hacker News agreed.

But again, macOS only. And the mosaic/blur feature wasn't as intuitive as I needed.

ShareX (Free & Open Source / Windows only)

On Windows, ShareX has a massive following. The feature set is enormous. But the moment I opened the settings panel, I understood why multiple reviews call it "overly complex."

I just want to add arrows. And it doesn't run on Mac.

Flameshot (Free & Open Source / Cross-platform)

An open-source tool that came back to life with v13.0 in August 2024 after a 3-year hiatus. It runs on Linux, Mac, and Windows. Finally, cross-platform!

But it's a desktop app that requires installation. My work PC doesn't have admin privileges. Dead end.

Lightshot (Free / Win & Mac)

This is where I got nervous.

Lightshot is popular, but it has a serious security flaw. Uploaded screenshots get a URL like prnt.sc/ followed by a 6-character alphanumeric code. You can guess URLs and view other people's screenshots. Personal info, bank account screenshots, API keys on screen — all exposed. Missouri University of Science and Technology blocked it on managed devices in August 2025.

Bug report screenshots contain internal information. Not an option.

The "No Install" Approach

Back to square one.

I listed my actual requirements:

Arrows, text, and mosaic blur (that's all I need)
Works on both Mac and Windows
No installation required (no admin rights on work PC)
Free (I'm not paying a subscription to add arrows)
Images never leave my machine (learned from the Lightshot incident)

Surprisingly few tools meet all five.

I tried browser-based tools like Annotely and Annotation.com. Not bad. But the workflow of "type URL → upload file → annotate → download" was far from Skitch's "capture → annotate → paste" experience.

PureMark Annotate runs as a PWA. Ctrl+V to paste an image, add annotations, Ctrl+C to copy. Everything happens in the browser — images are never sent to any server.

Before / After

Before (Skitch era):
Launch Skitch → drag screenshot → add arrows & text → copy to clipboard → paste in Slack

After (browser annotation):
Open Annotate in browser → Ctrl+V to paste → add arrows, text, mosaic → Ctrl+C to copy → paste in Slack

Nearly identical workflow. The difference: no installation. No OS restriction. And your images stay local.

Install it as a PWA, and it works just like a desktop app — even offline.

Comparison Table

Tool	Price	OS	Install	Privacy
Skitch	Free (discontinued)	macOS	Required	Local
Snagit	$39/year	Win/Mac	Required	Local
CleanShot X	$29 (updates $19/yr)	macOS	Required	Local
Shottr	Free	macOS	Required	Local
ShareX	Free	Windows	Required	Local
Flameshot	Free	All	Required	Local
Lightshot	Free	Win/Mac	Required	⚠️ URL guessing risk
PureMark Annotate	Free	All (browser)	Not required	Local only

Takeaway

What I loved about Skitch was that "just adding arrows" didn't come with baggage.

I couldn't find that simplicity in any desktop app. OS restrictions, admin permissions, subscriptions, privacy risks — every option required some compromise.

Opening a browser tab turned out to be the closest thing to Skitch.

Start annotating in 0 seconds → PureMark Annotate

References

Snagit 2025 Subscription Transition — TechSmith official
Lightshot blocked at Missouri S&T — University official news
Flameshot v13.0 — August 2024 release
CleanShot X — macOS screenshot tool

How I Grew My Developer Tool Suite to 175 MAU in 3 Weeks — Zero Ad Spend, Articles Only

tommy — Wed, 18 Mar 2026 03:12:41 +0000

"Nobody's Coming" Is the Worst Part

If you've ever shipped a side project, you know this feeling.

Launch day. Open Google Analytics. Real-time users: 0.

Next day, still 0. Day 3, finally 1 — it was me.

When I launched my developer tool suite, the first week's engaged MAU was 5. I didn't investigate how many were me.

Three weeks later, MAU hit 175. I spent zero on ads.

This is the full record — what worked, what flopped, and all the real numbers.

The tool suite discussed in this article is PureMark — 7 developer tools (JSON, Base64, Diff, JWT, Timestamp, and more) that work with zero clicks. Just copy something to your clipboard and open the page.

What I Built: 7 Tools, One Umbrella

Small tools developers use daily — JSON formatting, Base64 decode, URL encode, diff comparison, JWT decode, timestamp conversion — bundled into one branded suite.

Tool	What It Does
Annotate	Add arrows & text to screenshots (PWA)
JSON Formatter	Auto-formats on paste
Base64 Encoder/Decoder	One-action encode/decode
URL Encoder/Decoder	Percent-encoding conversion
Diff Checker	Text comparison with custom Myers diff
Timestamp Converter	Unix timestamp ↔ human-readable dates
JWT Decoder	Safely inspect tokens locally

Every tool shares one design principle: zero click. Copy something, open the page, and the result is already there. No Ctrl+V needed.

Plus a Chrome extension (PureMark Detect) that auto-detects clipboard format and opens the right tool in one click.

All the Numbers

No point hiding them, so here's everything:

MAU Growth

W10 (2/28–3/2):    5  ← Measurement started. Mostly me.
W11 (3/3–3/9):    80  ← Published 3 Zenn articles at once
W12 (3/10–3/14): 135  ← SEO accumulation kicking in
W13 (3/14–3/18): 175  ← Zero articles published. Organic only.

By Channel

Channel	W13 Numbers	Notes
Zenn (JP dev blog)	687 total PV / 13 likes	12 articles. +4 likes in a no-publish week
Dev.to	336 total PV	11 English articles
Google Search	22 impressions / 0 clicks	Still impression-only stage
Chrome Extension	23 installs	1 active user (painful)
X (Twitter)	1,242 impressions	Basically crickets

Ad spend: $0. Running costs: Cloudflare free tier + domain registration.

What Worked #1: Designing Articles as SEO Machines

90% of growth came from articles. But not random ones.

One Article = One Problem, Not One Tool

I never wrote "I built a JSON Formatter." Instead:

"Do You Know Where Your JWT Goes When You Paste It Into a Developer Tool?" — Lead with privacy concerns, introduce the tool as the solution
"130 Lines of Myers Diff From Scratch — And the Off-by-One Bug That Took 2 Days" — Lead with a real debugging story
"How I Turned My Development Logs Into Self-Accumulating Assets with Claude Code × Obsidian" — Lead with a workflow pain point

Every article starts with a problem the reader recognizes. The tool appears naturally as part of the solution.

Failure Stories Get Likes. Tutorials Don't.

After 12 articles, the pattern is unmistakable:

Articles That Got Likes	Common Thread
Skitch Alternative PWA (3 likes)	Flutter detour → PWA pivot. 3 hours on arrow rendering
Claude Code × Obsidian (5 likes)	2 AM frustration → bind mount solution
Myers Diff 130 lines (1 like)	Off-by-one bug that cost 2 days

Every article without a failure story got zero likes. n=12, no exceptions.

Try the zero-click experience yourself: visit JSON Formatter with some JSON in your clipboard — the result appears instantly.

What Worked #2: Making Tools "Refer" Each Other

This is why I built a suite instead of separate sites.

When you format JSON and there's a JWT token in your clipboard, the tool shows a button: "Looks like a JWT. Decode it?" Click it, and you're on the JWT Decoder with the token already parsed.

W13's cross-tool transition rate was 5.75% — 6 out of every 100 users moved from one tool to another.

This has compound effects: longer sessions improve Google's quality signals, and users discover tools they didn't know existed.

What Flopped — Spectacularly

Show HN → Zero

Posted to Hacker News. Result: 0 upvotes, 0 comments.

I'd analyzed it beforehand — developer tools are a saturated category on HN, and without genuine technical novelty (novel algorithm, unique architecture), it won't land. Knowing that in advance kept the emotional damage manageable.

Lesson: Pre-calibrate your expectations. "Light toss" mentality saved me from spiraling.

Share URL Feature → 4 Weeks at 0% Usage

Every tool has "recipe URLs" — encode input data in the URL hash so sharing a link reproduces the exact state. Technically elegant implementation.

Times used: Zero. Four consecutive weeks.

Button placement? No demand? I changed the UI in W13 — next week will tell.

X (Twitter) → Invisible

Tweeted. Made demo videos. Result: 1,242 impressions total, 3 likes.

Plenty of "use Twitter for indie marketing" advice out there. Reality: if your account has no followers, nothing reaches anyone. Not even good content.

Design Decisions That Mattered

"Everything Runs Locally" Pays Off Slowly

Every PureMark tool processes data in the browser. No server calls. Clipboard reading, JSON formatting, JWT decoding — all client-side.

Initially just a differentiator. But when I wrote the privacy-focused article, it got 2 likes in 4 days — fast for my scale. "Do you know where your JWT goes?" resonated. There's a real audience that cares about this.

KPI Dashboard Before Tools

I built the measurement infrastructure first. Cloudflare Workers + KV, pulling GA4/GSC/Zenn/Dev.to/X data every 6 hours into one dashboard.

Best decision I made. Without numbers, you can't tell what's working. The difference between "article week" and "no-article week" is visible in data, which makes the next action obvious.

3-Week Takeaways

Worked

Zenn article SEO accumulation — MAU grew +30% in W13 with zero new articles. Content is self-sustaining.
Story-driven articles — Only articles with failure stories earned likes.
Cross-tool navigation UI — 5.75% transition rate validates the suite strategy.
Dev.to English versions — GSC impressions from English queries growing.

Didn't Work

Show HN — 0 upvotes. Saturated category needs technical novelty.
X (Twitter) — Doesn't work without an existing audience.
Share URLs — 4 weeks at 0% usage. Feature ≠ adoption.

Still Unknown

When will GSC clicks start? — 22 impressions but 0 clicks. Need higher search rankings.
Chrome extension active rate — 23 installs, 1 active. Need a reason to keep using it.
Is this growth rate sustainable? — Gate 1 target is MAU 500 by mid-April. Need +11%/week.

Before / After

Before (3 weeks ago):
Built 7 tools. Was proud of them. MAU: 5. Show HN: 0. "Build it and they will come" was a lie.

After (now):
MAU 175. ~30% weekly growth. Users increasing even in weeks with no new content. What changed wasn't the product — it was spending equal time on "how to reach people" as on writing code.

In indie development, writing code is half the job. The other half is getting discovered, and there are reproducible methods for that.

All tools run in your browser. No sign-up, no data sent to servers. Try them → puremark.app

Do You Know Where Your JWT Goes When You Paste It Into an Online Tool?

tommy — Sat, 14 Mar 2026 00:19:53 +0000

The Moment I Froze

Pasting a JWT token into an online decoder. Throwing API response JSON into a formatter. Diffing code with an online tool.

If you're a developer, you probably do this every day.

I did too. One day, while decoding a JWT as usual, it hit me:

"This token contains the user's email and role info… where did it just get sent?"

I opened DevTools' Network tab. A POST request had fired. My input data was being sent to a server.

No malicious intent, obviously. Server-side processing is just how it's designed. But when you think about it, it's unsettling.

This experience led me to build PureMark — a developer tool suite that runs entirely in the browser. JSON / Base64 / URL / Diff / Timestamp / JWT — none of the six tools ever send your data externally.

It's Already Happening — Data Leaks Via Online Tools

"Am I overthinking this?" you might wonder. But incidents have already occurred.

80,000 AWS Keys Leaked (November 2025)

Security firm watchTowr Labs discovered that over 80,000 AWS keys, passwords, and API secrets had leaked from jsonformatter.org and codebeautify.org. Five years of stored data, over 5GB. Government agencies, banks, telecoms, and aerospace organizations were affected.

Developers had pasted data into these sites for JSON formatting and validation, and that data was stored on servers. It was provided as a "save" feature, but most users had no idea their credentials were being retained.

I also covered this in a previous article: JSON Formatter Dev Log: Zero-Click Formatting and Clipboard API Pitfalls

Samsung ChatGPT Incident (March 2023)

Samsung engineers input confidential source code and meeting transcripts into ChatGPT, leaking information externally. Three leaks occurred within just one month, forcing Samsung to ban internal ChatGPT usage.

This isn't about online tools specifically, but the risk of sending data to external services has the same structure.

The Structural Problem

I'm not here to criticize. Many online developer tools use server-side processing because it's easier to implement and handles complex operations well. It's a rational choice.

The problem is that users aren't aware of it.

JWT tokens contain claims like sub (user ID), email, role
API response JSON may contain customer data or internal IDs
Code pasted into diff tools might be unreleased feature implementations

Even if a privacy policy says "we don't store your data," risk isn't zero the moment data is transmitted.

Everything Could Run Client-Side

With PureMark, all six tools run entirely in the browser. Not a single line of server-side code.

Honestly, I first thought "is that even possible?" But when I investigated, browsers' standard APIs can do surprisingly much.

JSON Formatting: Done in 2 Lines

const parsed = JSON.parse(raw);
const formatted = JSON.stringify(parsed, null, 2);

Validation, formatting, minification — all done with JSON.parse + JSON.stringify. Absolutely no need to send to a server.

Base64: Browser Native API

const encoded = btoa(input);   // encode
const decoded = atob(encoded); // decode

Unicode support required combining with encodeURIComponent, but it still completes entirely in the browser.

JWT: Just Base64 Decode

JWT structure is three parts separated by dots: header.payload.signature. Header and payload are Base64URL-encoded JSON, so decoding reveals the claims.

const [header, payload] = token.split('.');
const claims = JSON.parse(atob(payload.replace(/-/g, '+').replace(/_/g, '/')));

Secret key signature verification isn't done on the frontend anyway (you can't expose the secret key in the browser). Decoding alone requires no server.

Try using PureMark, then open DevTools' Network tab. Besides GA4 beacons, you'll see zero external requests.

Try it: json.puremark.app / jwt.puremark.app

Diff: 130-Line Custom Implementation

This was the one exception where "2 lines with standard APIs" didn't cut it.

Displaying text differences requires the Myers diff algorithm. An external library would make it instant, but I wanted zero external dependencies. The result: about 130 lines of TypeScript.

What Went Wrong Without a Server

Client-side completion sounds ideal, but it comes with significant constraints. Here are the failures.

Myers Diff Off-by-One Bug

My custom Myers diff implementation produced a bug where highlight positions shifted on specific patterns.

The cause: an index calculation in backtrack processing used k where it should have been k - 1. A classic off-by-one error.

Tests passed. But it broke on edge cases.

I noticed the day after deployment and broke into a cold sweat. External libraries offer battle-tested code, but custom implementations carry this kind of risk. I still chose zero external dependencies to minimize bundle size and eliminate license risks.

2000-Character URL Limit

No server means no database to store shortened URLs.

My solution: a "recipe URL" approach. Base64-encode tool input data and embed it in the URL hash.

https://json.puremark.app/#d=eyJhYmMiOiJkZWYifQ&m=format

This restores tool state from the URL alone. No server needed.

...or so I thought, until slightly longer JSON exceeded 2000 characters. The browser URL length limit hits, and the share button grays out.

For now, I've accepted this limitation. Long data sharing falls back to a file download feature. A server could solve it by storing URL shortener keys in a DB, but that violates the "don't send data" principle. It was a trade-off.

SEO Disadvantage

SPAs can't do server-side rendering (SSR), which hurts search engine indexing.

I serve static HTML via Cloudflare Pages with pre-generated OGP images and meta tags. Still, compared to SSR frameworks like Next.js, SEO remains a handicap.

Why I Still Choose Client-Side

Constraints exist. But what you gain outweighs them.

Aspect	With Server	PureMark (No Server)
Where data goes	Sent to server	Never leaves browser
Monthly server cost	$20+ minimum	$0 (Cloudflare Pages free tier)
Offline support	Not possible	Works as PWA
Response speed	Network round-trip	Instant processing
User verifiability	Impossible if source is closed	Checkable via DevTools Network tab

User trust > SEO score.

That was my conclusion after building 6 tools in 2 weeks.

Before / After

Before	After
"Is this safe...?" every time pasting JWT into an online tool	Can verify with your own eyes that no requests are firing in Network tab
Hesitating to paste customer data into JSON formatters	No hesitation when data never leaves the browser
Afraid to paste unreleased code into diff tools	Don't even think about it with local processing
Opening different sites for each tool	One-click switching via PureMark's navbar

Data pasted into developer tools is more sensitive than you think. Once I realized that, I started paying attention to what's happening behind the tools I use.

PureMark was born from that realization — a tool I myself can use with peace of mind.

Try it: puremark.app — JSON / Base64 / URL / Diff / Timestamp / JWT, all browser-complete.

References

What If the Page Could Detect Data Formats Without Copying? — Adding Page Scan + JWT Detection to a Chrome Extension

tommy — Fri, 13 Mar 2026 22:26:44 +0000

The Limits of Clipboard Detection

In my previous article, I built a Chrome extension that auto-detects clipboard data formats. Copy → click icon → detect → open in tool. Handy.

After using it for a while, something bugged me.

I was reading a Qiita article. A JSON API response was displayed in a <pre> block. Deeply nested, hard to read. I wanted to format it.

I selected the JSON with my mouse. Ctrl+C. Clicked the extension icon. Popup opened. "Format JSON" appeared. Clicked. Tool opened and formatted it.

Wait — the data is already on screen. Why do I need to copy it?

There was another problem. Copying JSON from Japanese tech blogs introduced smart quotes ("" → "") and trailing commas. The CMS silently converts quotes to "pretty" curly quotes. On screen it looks like "name", but the clipboard contains \u201Cname\u201D. JSON.parse() fails instantly.

"If I scan the code blocks directly from the page, no copying needed, and no CMS interference."

Built it.

Chrome extension PureMark Detect is available on the Chrome Web Store.

PureMark Detect — Chrome Web Store

PureMark — JSON, Base64, URL Encode, Diff, Timestamp, and JWT tools, all in your browser

What Changed in v1.2.0

Three new features.

1. Inline Preview

You can now see conversion results right inside the popup. JSON gets formatted, Base64 gets decoded, timestamps get converted. No need to open the full tool when you just want a quick peek.

Copy button included — paste the result anywhere.

2. Page Scan

Hit "Scan this page" in the popup, and it scans all <pre> and <code> elements on the page. For blocks containing JSON, Base64, URL Encoded text, Unified Diff, or Unix Timestamps, action buttons are injected below the code block.

No copying. No selecting. Just click the button under the code block you're interested in.

3. JWT Detection

v1.2.0 adds JWT (JSON Web Token) detection. When it finds a token starting with eyJhbGciOi..., it decodes the header and payload right in the inline preview. With expiration badge.

JWT is Base64url-encoded, so it conflicts with existing Base64 detection. The fix was simple. Since JWT headers encode {"alg":...} in Base64url, they always start with eyJ. A regex checks this first:

// JWT detection — prioritized over Base64
test: (text: string) =>
  /^eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+$/
    .test(text.trim()),

eyJ + three dot-separated parts is enough to accurately separate JWT from Base64. Both header and payload start with eyJ (= Base64url of {), which is a structural characteristic of JWT. Just prioritizing JWT → Base64 in the detection order was enough for coexistence.

Decoded results link to JWT Decoder for claim explanations and expiration visualization.

Content Script Blew Up on `import`

Page scanning requires injecting code into the page as a Content Script. The detection logic was already implemented in detectors.ts on the popup side, so I just imported it —

Uncaught SyntaxError: Cannot use import statement

Content Scripts don't load as ES Modules.

Manifest V3 Service Workers support ES Modules, but Content Scripts still use the legacy script injection approach. import statements don't work.

To share detection logic between popup and Content Script, a separate build for the Content Script is needed.

// vite.config.content.ts — Content Script dedicated build
export default defineConfig({
  build: {
    outDir: 'dist',
    emptyOutDir: false, // Don't wipe the main build output
    lib: {
      entry: resolve(__dirname, 'src/content/scanner.ts'),
      formats: ['iife'], // ← Self-contained bundle
      fileName: () => 'content-scanner.js',
    },
  },
});

Bundling as iife (Immediately Invoked Function Expression) eliminates all import statements and inlines everything into a single file. The build command becomes two-stage:

vite build && vite build --config vite.config.content.ts

First build for popup and Service Worker, second for Content Script. Forget emptyOutDir: false and the first build's output gets nuked.

The Smart Quote Battle

The real reason for implementing page scan was that clipboard-based detection was unreliable.

Copying JSON from Japanese tech blogs produced this:

{"name": "value"}  ← What you see on screen
{"name": "value"}  ← What actually lands in clipboard

Indistinguishable. But "" (U+201C, U+201D) is not "" (U+0022). JSON.parse() fails immediately.

The fix: Unicode normalization before detection:

function normalizeQuotes(text: string): string {
  return text
    .replace(/[\u201C\u201D\u201E\u201F\u2033\u2036\uFF02]/g, '"')
    .replace(/[\u2018\u2019\u201A\u201B\u2032\u2035\uFF07]/g, "'");
}

7 varieties of double quote variants and 7 single quote variants. This alone dramatically improved JSON detection from Japanese blogs.

Plus trailing comma removal and { {...}, {...} } → [{...}, {...}] array bracket correction. Rescuing the "slightly broken JSON" that blog CMSes generate.

Page scan reads raw DOM text directly, bypassing CMS smart quote conversion. Try it with PureMark Detect.

"Hello World" Detected as Base64

After implementing page scan and JWT detection, I tested on various sites.

One page had Hello World in a code block. Detected as Base64.

"Hello World" is not Base64.

But character-wise, HelloWorld matches [A-Za-z0-9+/]. atob() doesn't throw either. The two-stage filter of regex + actual decode verification wasn't enough.

Final solution:

function isBase64(text: string): boolean {
  const trimmed = text.trim();
  if (trimmed.length < 16) return false;
  if (/^[A-Za-z]+ [A-Za-z]/.test(trimmed)) return false; // Exclude English text
  if (!/^[A-Za-z0-9+/\s]+=*$/.test(trimmed)) return false;
  try { atob(trimmed.replace(/\s/g, '')); return true; }
  catch { return false; }
}

Minimum length raised to 16 characters, and "English word + space + English word" pattern rejected upfront. Page scan processes many code blocks, so it needs to be far stricter about false positives than clipboard detection.

Summary

Before (v1.0):

Select text → Copy → Click icon → Detect → Open tool
Smart quote contamination breaks detection
Must open full tool to see results
JWT misdetected as Base64

After (v1.2):

"Scan this page" → Auto-detect code blocks → Button click to jump to tool
No copying. No selecting. Reads raw DOM, bypassing smart quote issues
Inline preview shows conversion results without leaving the page
JWT correctly detected with header/payload decode display

Technically, the four key challenges were: Content Script IIFE builds, Unicode normalization, Base64 false positive prevention, and JWT detection priority design. All born from "it broke when I actually used it" — none predictable at design time.

PureMark Detect — Chrome Web Store | PureMark — Zero-click start, simply.

I Built a JWT Decoder and Lost Half a Day to atob()

tommy — Wed, 11 Mar 2026 10:48:17 +0000

During development, I constantly need to check what's inside a JWT.

Every time, I'd open jwt.io, paste the token, read the payload, and switch back to the editor. This back-and-forth was surprisingly tedious. And pasting auth tokens into an external site always felt a bit uncomfortable.

"Let me build a decoder that works locally."

The finished decoder is here. It auto-detects JWTs from your clipboard and decodes them.
👉 jwt.puremark.app

A JWT is just three parts joined by .. Base64-decode them and you can see the contents. Should be easy — or so I thought.

Trap 1: `atob()` Doesn't Work

I extracted the payload part of a JWT and passed it to JavaScript's atob().

const payload = "eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ";
const decoded = atob(payload);
// => DOMException: String contains an invalid character

It doesn't work.

After investigating, I found the cause. JWT uses Base64url, not Base64. They look similar but are different.

	Standard Base64	Base64url
62nd character	`+`	`-`
63rd character	`/`	`_`

The characters are replaced with URL-safe alternatives. atob() only accepts standard Base64, so passing Base64url directly throws an error.

The fix is just two replace calls.

const base64 = payload.replace(/-/g, '+').replace(/_/g, '/');
const decoded = atob(base64);
// => {"sub":"1234567890","name":"John Doe","iat":1516239022}

It works. "Is that all?" I thought — but it's the kind of trap you'd be stuck on forever if you didn't know about it.

Trap 2: The Padding Problem Strikes Again

I felt safe after fixing Trap 1. Then I tried a different JWT and got the same error.

DOMException: String contains an invalid character

Same error. But this time there were no - or _ characters.

The cause was padding. Standard Base64 pads strings to a multiple of 4 with =. But Base64url omits the =. atob() sometimes rejects input without proper padding.

The fix is straightforward. Add = based on the remainder when dividing the string length by 4.

const pad = base64.length % 4;
if (pad === 2) base64 += '==';
else if (pad === 3) base64 += '=';

Remainder of 2 → ==, remainder of 3 → =. That's it. But the time I spent testing every JWT and wondering "why does only this one fail?" was definitely half a day.

UTF-8 Support: Enter `TextDecoder`

On top of that, JWTs with Japanese characters in the payload produced garbled text. atob() treats everything as Latin-1, breaking multibyte characters.

The final decode function looks like this:

function base64UrlDecode(str) {
  let base64 = str.replace(/-/g, '+').replace(/_/g, '/');
  const pad = base64.length % 4;
  if (pad === 2) base64 += '==';
  else if (pad === 3) base64 += '=';

  const binary = atob(base64);
  const bytes = new Uint8Array(binary.length);
  for (let i = 0; i < binary.length; i++) {
    bytes[i] = binary.charCodeAt(i);
  }
  return new TextDecoder().decode(bytes);
}

Trap 1 (character conversion) + Trap 2 (padding) + UTF-8 support. All together, 13 lines. It took half a day to arrive at these 13 lines.

Design Decision: No Signature Verification

"A JWT decoder that doesn't verify signatures?"

Correct. The reason is clear: the purpose of a decoder is to inspect the contents. Signature verification is the server's job. Holding secret keys on the client side is a security risk, and the algorithms vary widely.

However, there's one absolute line to draw:

Decode ≠ Trust

Just because you can decode a JWT and see its contents doesn't mean you should trust them. Without signature verification, tampering cannot be detected. A decoder is strictly a development inspection tool. If you use decoded results for authentication or authorization decisions, always verify signatures on the server side.

Bonus: Auto Claim Descriptions and Expiry Badges

Once decoding works, the next thing you want is "what does this claim mean?" exp, iat, iss — JWT standard claims use abbreviations that are hard to remember.

I added descriptions for 15 major claims.

Claim	Description
`iss`	Issuer
`sub`	Subject
`aud`	Audience
`exp`	Expiration Time
`nbf`	Not Before
`iat`	Issued At
`jti`	JWT ID

For timestamp claims like exp, nbf, and iat, I display not just Unix seconds but also ISO 8601 format + relative time ("3 hours ago", "in 5 days").

Expiry badges are also implemented. Green for valid, red for expired, yellow for not-yet-valid. No need to paste into jwt.io — check your token's status at a glance at jwt.puremark.app.

Decoded payloads can also be formatted with JSON Formatter or the original encoded string can be checked with Base64 Decoder. Cross-tool navigation links are included.

Before / After

	Before	After
JWT inspection	Copy-paste to jwt.io. Token sent to external site	Runs locally. Auto-detects from clipboard
`atob()`	Pass Base64url directly → error	Insert `-`→`+`, `_`→`/` conversion
Padding	Some JWTs fail mysteriously	Check `% 4` remainder and append `=`
Claims	Look up `exp` every time	Auto descriptions + relative time display

The lessons from half a wasted day are condensed into a 13-line function. I hope this article saves you that half day.

JWT Decoder → jwt.puremark.app

References

I Built a Unix Timestamp Converter and Stepped on 3 JavaScript Date API Landmines

tommy — Sun, 08 Mar 2026 09:23:43 +0000

An API response returns 1709654400.

Can you tell what date that is at a glance? I couldn't. Every time, I'd google "Unix Timestamp converter" and paste it into some online tool. That tiny friction adds up, so I decided to build my own converter.

Try it out: timestamp.puremark.app — zero-click timestamp conversion, right in your browser.

I got it working, but not before stepping on 3 landmines in JavaScript's Date API.

Landmine 1: `new Date(1709654400)` Returns 1970

I started confidently. Just pass the timestamp to new Date().

const date = new Date(1709654400);
console.log(date.toISOString());
// => "1970-01-20T21:34:14.400Z"

Way off.

The cause was simple: JavaScript's Date expects milliseconds, but Unix timestamps are in seconds. You need to multiply by 1000.

const date = new Date(1709654400 * 1000);
console.log(date.toISOString());
// => "2024-03-05T00:00:00.000Z"

But should users have to think about whether they're entering seconds or milliseconds? No. I implemented auto-detection by digit count: 10 digits = seconds, 13 digits = milliseconds.

function toMillis(input) {
  if (/^\d{10}$/.test(input)) return Number(input) * 1000;
  if (/^\d{13}$/.test(input)) return Number(input);
  return NaN;
}

Three lines. But without them, every input becomes a guessing game.

Landmine 2: Hyphens and Slashes Parse Differently

Next, I added date-string-to-timestamp conversion. Type 2024-03-05, get the Unix timestamp. Should be simple.

console.log(new Date('2024-03-05').toISOString());
// => "2024-03-05T00:00:00.000Z" (UTC)

console.log(new Date('2024/03/05').toISOString());
// => "2024-03-04T15:00:00.000Z" (JST midnight = UTC previous day)

Same date, different separators, completely different results. Hyphens get parsed as UTC (ISO 8601), slashes get parsed as local time (implementation-dependent).

MDN says it clearly:

Parsing date strings with the Date constructor is strongly discouraged due to browser differences and inconsistencies.

The lesson: never trust new Date() with non-ISO-8601 strings.

Landmine 3: The Timezone Display Maze

Once conversion worked, I wanted a timezone comparison table — "What time is this in Tokyo? New York? Berlin?"

My first attempt was getTimezoneOffset().

const offset = new Date().getTimezoneOffset();
console.log(offset); // JST: -540

The sign is inverted. JST is UTC+9, but getTimezoneOffset() returns -540 minutes (= -9 hours). Plus, it only returns the user's local timezone — you can't get arbitrary timezones with it.

The solution: Intl.DateTimeFormat.

const date = new Date('2024-03-05T10:00:00Z');
date.toLocaleString('en-US', {
  timeZone: 'Asia/Tokyo',
  hour12: false,
  year: 'numeric', month: '2-digit', day: '2-digit',
  hour: '2-digit', minute: '2-digit', second: '2-digit'
});
// => "03/05/2024, 19:00:00"

Just pass an IANA timezone identifier to the timeZone option. No external libraries needed. I implemented a 10-timezone comparison table covering UTC, JST, EST, PST, CET, GMT, IST, CST, AEST, and BRT.

See it in action: timestamp.puremark.app shows your timestamp across 10 cities at a glance. Each row has a copy button for pasting into Slack or Jira.

Before / After

	Before	After
Checking timestamps	Google → copy-paste to some online tool	Just open a browser tab. Auto-reads from clipboard
Seconds vs milliseconds	Count digits manually	Auto-detected. Don't even think about it
Date string parsing	Trust `new Date()`, get bitten by browser differences	Know that non-ISO-8601 is unreliable
Timezones	Confused by `getTimezoneOffset()` sign	`Intl.DateTimeFormat` with 10-city display

All three landmines are "obvious once you know" but can cost you hours if you don't. Hope this article saves you that time.

Timestamp converter → timestamp.puremark.app

References

I Almost Signed Up for API Access. Claude Code Was Already in My $20 Pro Plan.

tommy — Sat, 07 Mar 2026 22:22:56 +0000

I Nearly Double-Paid

Claude Code caught my attention. Call Claude from the terminal. Read and write files directly. Understand an entire codebase and make fixes across it.

"I need this," I thought, and opened the Anthropic website. Claude Console, API keys, usage-based billing... "So it's a separate subscription on top of Pro," I assumed. $20/month plus API charges. I hesitated.

A few days later, I re-read the official docs and spotted this:

Pro and Max plans now include access to both Claude on web, desktop, and mobile apps, as well as Claude Code in the terminal, all under one unified subscription.

It was included in the Pro plan ($20/month). No additional contract needed. No API key required.

This article is for Claude Pro subscribers. If you're interested in practical Claude Code workflows, I wrote about that too:
Claude Code x Obsidian: Turning AI Work Logs into a Knowledge Base

Installation Is 3 Lines

If you have Node.js 18+, there are exactly three things to do:

npm install -g @anthropic-ai/claude-code  # Install
claude                                     # Launch (opens auth on first run)
# -> Log in with your Pro plan account. That's it.

No API key generation. No Console configuration. Just log in with your Pro account and start using it.

Anticlimactically easy.

When You Hit the Limit, Don't Press "YES"

The Pro plan has usage caps. If you're using Claude Code heavily, you'll eventually see this:

You've reached your usage limit. Use API credits to continue?

If you press YES, you switch to usage-based billing.

At first I thought, "I don't have an API key, so I'm safe." Wrong.

Pressing YES triggers the Claude Console (API management) sign-up flow. If you proceed, usage-based billing starts even without an explicit API key. And Auto-reload (automatic credit purchase when balance runs low) may be on by default.

In other words, there's a path from "hit limit -> YES -> sign up -> surprise charges."

Scenario	What Happens When You Press YES
No Console account	Redirected to sign-up flow. No charges if you don't complete it
Console exists, Auto-reload off	Consumes existing credit balance only
Console exists, Auto-reload on	Balance depleted -> auto-purchase -> charges start

How to Stay Safe

When the limit prompt appears, choose "No" (just wait for the reset)
As a precaution, visit console.anthropic.com/settings/billing and turn Auto-reload off

That's it. No charges beyond $20/month.

Curious what you can build with Claude Code? I built the developer tool suite PureMark from Phase 0 through Phase 4 entirely with Claude Code.

Claude Desktop vs. Claude Code

"If I already have Claude Desktop, why do I need Claude Code?" I had the same question. Here's what I found:

	Claude Desktop	Claude Code
File access	Upload or paste into chat	Reads and writes local files directly
Codebase awareness	Feed files one at a time	Automatically understands the entire project
Git operations	Not available	Commit, push — end to end
MCP integration	Available with config	Available with config
Interface	GUI chat	Terminal CLI

The biggest difference: whether it can directly touch your files. With Claude Desktop, you manually feed files into the conversation. Claude Code uses Read, Edit, and Write tools to operate on local files directly. Because it understands the full codebase, it figures out "that other file needs to change too" on its own.

Takeaways

Before:

Assumed Claude Code required a separate API contract
Was mentally prepared for $20/month + API usage fees
Kept putting off the setup as a result

After:

Pro plan ($20/month) includes Claude Code — no extras
Installation is 3 lines; authentication is just logging in with your Pro account
As long as you say "No" at the usage limit prompt, no additional charges

Claude Code is easier to get started with than you'd think. If you know someone hesitating because of the API pricing page, tell them: "It's already in your Pro plan."

Claude Code Official Docs

PureMark — Zero-click simplicity for developers.

References

I Implemented Myers Diff in 130 Lines, Then Lost Half a Day to an Off-by-One Bug

tommy — Sat, 07 Mar 2026 22:22:49 +0000

I Didn't Want Another Dependency

I could have installed a diff library and been done in five minutes. I know.

But my developer tool suite PureMark has a strict zero-dependency policy. The JSON Formatter, Base64 decoder, URL Encoder — all hand-written. Letting the Diff Checker be the one exception didn't sit right.

Besides, I use git diff every single day, and I couldn't explain what was actually happening behind the scenes. That bothered me.

Turns out, it's a 1986 algorithm by Eugene Myers. git diff, the Unix diff command — they all use it under the hood. Nearly 40 years old and still the standard. When I implemented it, it fit in about 130 lines of TypeScript.

This article covers how the algorithm works and the off-by-one bug that cost me half a day.

Try the finished product here: PureMark Diff Checker
Paste two blocks of text and see the diff highlighted instantly.

Reframing Diff as a Shortest Path Problem

The core insight of Myers' algorithm is turning a diff problem into a shortest-path problem on a graph.

Given two texts A (old) and B (new), imagine a grid with A on the x-axis and B on the y-axis:

     B[0]  B[1]  B[2]  B[3]
      |     |     |     |
  (0,0)-->(1,0)-->(2,0)-->(3,0)-->(4,0)
    |  \    |  \    |       |       |
    v   \   v   \   v       v       v
  (0,1)-->(1,1)-->(2,1)-->(3,1)-->(4,1)
    |       |  \    |  \    |       |
    v       v   \   v   \   v       v
  (0,2)-->(1,2)-->(2,2)-->(3,2)-->(4,2)

-> Right  = Delete (remove a line from A)
|  Down   = Insert (add a line from B)
\  Diagonal = Match (cost 0)

The shortest path from (0,0) to the bottom-right corner gives you the minimal edit sequence.

Diagonal moves cost zero — when lines match, you skip ahead for free. That's the source of Myers' efficiency.

The algorithm increments the edit distance d = 0, 1, 2, ... one step at a time, recording the farthest reachable point at each step. Once it reaches the goal, it backtracks to reconstruct the edit sequence.

This "shortest path on a coordinate grid" mental model makes both the algorithm and the implementation far more approachable.

130 Lines. It Worked. Or So I Thought.

Here's the core:

function myers(a: string[], b: string[]): EditOp[] {
  const n = a.length, m = b.length, max = n + m;
  const v = new Int32Array(2 * max + 1);
  const offset = max;
  v[offset + 1] = 0;
  const trace: Int32Array[] = [];

  for (let d = 0; d <= max; d++) {
    trace.push(v.slice());  // Snapshot the V array
    for (let k = -d; k <= d; k += 2) {
      let x = (k === -d || (k !== d && v[offset+k-1] < v[offset+k+1]))
        ? v[offset+k+1] : v[offset+k-1] + 1;
      let y = x - k;
      while (x < n && y < m && a[x] === b[y]) { x++; y++; }
      v[offset + k] = x;
      if (x >= n && y >= m) return backtrack(trace, offset, n, m, a, b);
    }
  }
  return backtrack(trace, offset, n, m, a, b);
}

Key points:

Int32Array makes slice() snapshots fast
The trace array stores V state at each step — the key to backtracking
The while loop (diagonal follow) skips matching lines at zero cost

I tested it. Short text diffs — perfect. JSON comparisons — no issues. Longer code blocks — looked correct.

I deployed.

The Bug Showed Up the Next Day

Long text, and the diff display was wrong. Deletions and insertions were in the wrong positions.

Short texts worked fine. But as line counts grew, the path drifted. Classic off-by-one smell.

I traced through the backtrack function — the part that walks backward from the goal, reconstructing "which diagonal were we on at each step." The problem was one line:

- const v = trace[d - 1];  // Wrong
+ const v = trace[d];      // Correct

Why I got it wrong.

trace.push(v.slice()) runs at the beginning of each loop iteration. So trace[d] holds "the V state before step d starts" — which is the same as "the V state after step d-1 completes."

To unwind step d, you need the state at the start of step d — that's trace[d], not trace[d-1].

The trap is the intuition that "trace[d] was saved during step d, so it must contain the state after step d." Wrong. Because the save happens at the top of the loop, it actually contains the state before step d.

With short texts, d stays small and the path drift doesn't surface. With long texts, d grows large, and a one-step offset snowballs into a visible bug.

The scary thing about this bug: short test cases won't catch it. I had unit tests, but the test data was too small. Bugs that only manifest with production-sized data are the most dangerous kind.

After the fix, I added long-text test cases. All tests pass.

See this implementation in action: PureMark Diff Checker
Toggle between side-by-side and unified views to compare how diffs are displayed.

Bonus: Solving Key Order in JSON Diff

Text diff alone has a problem with JSON.

{ "a": 1, "b": 2 } and { "b": 2, "a": 1 } are semantically identical, but a text comparison shows them as different. The solution: recursively sort keys before comparing.

function sortKeys(value: unknown): unknown {
  if (value === null || typeof value !== 'object') return value;
  if (Array.isArray(value)) return value.map(sortKeys);
  const sorted: Record<string, unknown> = {};
  for (const key of Object.keys(value as Record<string, unknown>).sort()) {
    sorted[key] = sortKeys((value as Record<string, unknown>)[key]);
  }
  return sorted;
}

JSON.parse() -> sort keys -> JSON.stringify(null, 2) -> regular text diff. That's all it takes for key-order-independent structural comparison. In PureMark Diff Checker, there's a "JSON Diff" toggle for this.

Takeaways

Before	After
Diff was a black-box library	Implemented in 130 lines
No idea how the algorithm worked	"Shortest path on a grid" — simple mental model
External dependency bloating the bundle	Zero dependencies, minimal bundle

The biggest lesson: the off-by-one bug wasn't in the algorithm logic itself — it was in how I read the data structure. The trace array's save timing (top of loop vs. end of loop) was the entire issue. Short test cases can't find it. Bugs that only show up with real-world data are the scariest.

Before reaching for a library, try implementing it yourself. 130 lines of investment, and git diff output went from "magic" to "something I actually understand."

PureMark Diff Checker | PureMark — Zero-click simplicity for developers.

References

An O(ND) Difference Algorithm and Its Variations (Eugene Myers, 1986) — The original paper
The Myers diff algorithm (blog.jcoglan.com) — An excellent walkthrough series
PureMark — Developer tool suite

Claude Desktop to Claude Code: What I Learned Rebuilding My AI Dev Environment 3 Times

tommy — Sat, 07 Mar 2026 22:13:13 +0000

I Had All the Tools. Nothing Worked.

"I want to use AI to make my development faster."

With that thought, I installed every tool I'd heard about — Cursor, Claude Desktop, Obsidian, GitHub. I configured MCP connections, grabbed API keys, designed directory structures, and mapped out workflows.

Then I tore it all down and rebuilt it. Three times.

Looking back, the reason is clear. I started with tools before deciding what I actually needed to do.

This article isn't a setup guide. It's the story of three configurations I actually lived through — what broke, what clicked, and why each transition happened. If you've installed a bunch of AI tools and still feel like you're not getting the most out of them, this might resonate.

Building something with AI tools? I built Pure Mark Annotate — a PWA image annotation tool — using the exact workflow described in this article. Zero friction, browser-based. The tool and the process are inseparable.

The Two Configurations Compared

	Config A (Initial)	Config B (Current)
Editor	Cursor	Cursor
AI	Claude Desktop	Claude Code
Knowledge mgmt	Obsidian (via MCP)	Obsidian (direct file access)
Research & writing	Claude only	Gemini API integration
Git/GitHub	Manual	Directly from Claude Code
Persistent settings	User Preferences	CLAUDE.md
Monthly cost	Pro $20	Pro $20 (same)

Bottom line: The tool choice mattered less than how clearly I'd defined my goal.

The Drift Before Purpose

Phase 0: "I want AI to make development faster" (vague)

That was the starting motivation. Combine Cursor with Claude Desktop and something amazing will happen, right?

At this stage, I couldn't articulate what to make faster. So even after installing everything, I kept thinking, "Okay, now what?"

Phase 1: "I want to accumulate knowledge in Obsidian" (somewhat specific)

Knowledge from AI chat sessions disappeared every time the session ended. That felt like waste. "What if conversations automatically accumulated in Obsidian?" — that was the first real goal.

→ Built Config A with Claude Desktop + mcp-obsidian

Phase 2: "I want to automate article writing too" + "I want AI to handle Git" (specific)

Not just storing knowledge — I wanted to write articles from it, push to GitHub, and publish to Zenn (a developer blogging platform). Claude Desktop can't run terminal commands, so I hit a wall.

→ Migrated to Config B with Claude Code + Gemini + GitHub

Every time the goal got sharper, the required setup changed. That's why I rebuilt three times.

Config A: Cursor + Claude Desktop + Obsidian

Goal at the time: "Chat with AI while saving notes to Obsidian"

What Worked

Setup was intuitive. Claude Desktop is install-and-login. Configure MCP server connections through the GUI, enable Obsidian's local REST API plugin, and Claude Desktop can read/write Obsidian files. Simple.

The chat UI is approachable. Even non-engineers can start immediately. "Save this to Obsidian" — and MCP handles it.

What Broke

Problem 1: Files created in WSL were invisible to Obsidian

This was the first and biggest trap.

# Created a file from WSL
echo "# Test" > ~/vault/test.md

# → Obsidian (Windows side) can't see it!

The reason was simple: before configuring automount, WSL local paths and Windows-side Obsidian paths are completely different locations. The file exists, but Obsidian can't see it.

WSL:     ~/vault/test.md        ← file created here
Windows: C:\Users\...\Obsidian\ ← test.md doesn't exist here

"File exists != Obsidian can see it." It took embarrassingly long to figure that out.

Problem 2: MCP connections were flaky

File operations through MCP worked... when they worked. Depending on when Obsidian's REST API plugin started up or the MCP connection state, writes would sometimes fail silently. "Saved successfully" — but nothing was saved.

Problem 3: Re-explaining rules to AI every session

Claude Desktop has User Preferences for persistent settings, but it has limits. I kept having to re-explain project-specific rules ("Use MCP tools for Obsidian writes," "The path is X") every session.

I ended up writing rules like this in User Preferences:

# Obsidian Rules (Required)
- USE mcp-obsidian:obsidian_append_content
- DO NOT create files in WSL local paths
- Reason: Without automount, files end up in the wrong location

It worked, but "teaching AI the rules every time" was itself the inefficiency I was trying to eliminate.

Problem 4: Terminal access requires stacking more MCPs

Claude Desktop can't run terminal commands on its own. You can add a Local Shell MCP server or GitHub MCP server, but each new capability means another MCP in your config.json. Obsidian needs mcp-obsidian, terminal needs Shell MCP, GitHub needs GitHub MCP...

The more connections, the more instability. I started spending time figuring out which MCP was running and which had silently dropped.

Claude Code has file operations, terminal, and Git built in natively. That difference became decisive as the MCP stack grew.

The original goal — "chat with AI while taking notes" — was well served. But when the goal shifted to "automate the entire dev workflow," the MCP-stacking approach hit its ceiling.

Config B: Cursor + Claude Code + Gemini + Obsidian + GitHub

The goal changed: "Run my entire dev workflow through AI"

Write code
Run tests and builds
Accumulate knowledge in Obsidian
Write articles and publish them
Manage GitHub issues and PRs

All of this, from one environment, in conversation with AI.

What Worked

1. Direct Obsidian Access — Finally Stable

Claude Code runs inside WSL. After configuring automount (bind mount), it can Read/Edit/Write directly to ~/vault/. No MCP intermediary means no flaky connections.

# Config A (Claude Desktop)
Claude → MCP connection → Obsidian REST API → file operation
                        ↑ This was unreliable

# Config B (Claude Code)
Claude Code → Read/Edit/Write → ~/vault/
              ↑ Native WSL operation. Stable.

2. CLAUDE.md — The Project's Memory

This was the single biggest improvement in Config B.

Place a CLAUDE.md file in your project root, and Claude Code automatically reads it at the start of every session.

# CLAUDE.md (excerpt)
## Obsidian Rules
- Use Read/Edit/Write tools for direct file access (preferred)
- Use mcp-obsidian only as fallback

## Article Writing Workflow
- Gemini research → outline review → Gemini draft → Claude review → publish

## GitHub Rules
- Always verify remote is private before git push

Config A's User Preferences were global — applied to every conversation. CLAUDE.md is per-project and version-controlled in Git.

The "re-explaining rules every session" problem was solved at the root.

3. Terminal Access — Just There

# Tell Claude Code "run the tests"
npm test

# Git — directly
git add . && git commit -m "feat: new feature" && git push

# GitHub CLI — directly
gh pr create --title "New feature" --body "Summary..."

Chat and terminal are unified. The development flow never breaks when collaborating with AI.

4. Claude + Gemini: Division of Labor

Instead of making Claude do everything, I split responsibilities by strength.

Role	Owner
Research, drafting, image generation	Gemini API
Quality review, editorial judgment	Claude (editor-in-chief)
Code, Git operations	Claude Code
Knowledge accumulation	Obsidian (direct access)

When writing an article, Claude orchestrates the loop: "Have Gemini research → review the outline → have Gemini draft each section → Claude reviews." Automated.

What Broke

Problem 1: Automount Configuration — Trial and Error

File sharing between WSL and Windows required automount (bind mount) setup. Get the /etc/fstab entry wrong and WSL won't boot. Tread carefully.

# Added to /etc/fstab (get it wrong and WSL won't start)
/mnt/c/Users/.../Obsidian/auto-empire ~/vault none noauto,x-systemd.automount,bind,... 0 0

I tried symlinks first, but some AI agents refused to write through symlinks. Ended up with automount.

Problem 2: Learning to Write CLAUDE.md

There's no established best practice for writing CLAUDE.md. I initially stuffed too much in, which made Claude Code's behavior erratic.

Through trial and error, I landed on these principles:

Keep rules short and explicit (move long explanations to separate files)
Include path mapping tables (so Claude Code doesn't guess wrong)
State "don't do this" rules explicitly (e.g., "Never write code directly via GitHub API")
Define trigger commands (e.g., "write an article about X" → auto-launches the workflow)

Problem 3: CLI Takes Getting Used To

Compared to Claude Desktop's "type in a chat window and send" experience, Claude Code is terminal-based. Even inside Cursor's terminal, there's an initial "where do I talk to this thing?" moment.

That said, Cursor's Claude Code extension provides an in-editor UI, so it's mostly a familiarity issue.

This is the workflow I used to build Pure Mark Annotate. Claude Code orchestrating the dev loop, Obsidian accumulating decisions, Gemini handling research. The same system described here, running in production.

Your Goal Determines Your Setup

After rebuilding three times, I'm certain of one thing:

The first step isn't setting up your environment. It's articulating what you want to do.

"Claude Code or Claude Desktop — which is better?" has no universal answer. It depends on your goal.

Recommended Config by Goal Clarity

Your Goal	Recommended Setup	Why
Chat with AI	Claude Desktop alone	Sufficient. No extra setup
Chat + save notes to Obsidian	Claude Desktop + mcp-obsidian	One MCP connection does it
Dev + knowledge accumulation	Cursor + Claude Code + Obsidian	Direct file ops are stable
Automate the full dev workflow	Cursor + Claude Code + Gemini + Obsidian + GitHub	All-in. High setup cost

The key: start from the top row and work down.

If you build the full-stack config first, you'll get buried in setup and lose sight of your actual goal. Wait until "what's missing" becomes obvious, then add the next layer.

"Starting With Tools" Leads to Config Hell

My failure pattern looked like this:

1. "Claude Code is amazing" → Install
2. "MCP can connect to Obsidian" → Configure
3. "Gemini API is available too" → Add it
4. "Wait, what was I trying to do...?"

Starting from the goal, it looks like this:

1. "I want to automate writing articles through to publishing" ← Goal
2. "Research with Gemini, editorial with Claude" ← Role split
3. "I need terminal access → Claude Code" ← Tool selection
4. "Knowledge in Obsidian → need WSL integration → automount" ← Env setup

You arrive at the same tools, but in reverse order. When you start from the goal, each tool has a clear "why," and setup decisions stop being ambiguous.

Summary

Before (tool-first, no goal):

Install tools, drown in config
"What was I doing again?" on repeat
Rebuilt the environment 3 times

After (goal-first, then config):

Say "write an article" and the pipeline runs from research to publication
CLAUDE.md serves as the project's persistent memory
Knowledge accumulates automatically from conversations

The first thing you should do isn't installing the latest tool.

It's writing down "What do I want AI to do for me?" in a notebook.

Once that's clear, the right setup reveals itself.

Next Steps

Write down "things I want AI to handle" in bullet points — on paper or in Obsidian
Pick the config that matches your current goal clarity from the table above
Add the next tool only when you feel what's missing

Very few people need the full-stack setup. Start minimal.

References

Pure Mark Annotate — Zero-friction image annotation in your browser

Share Tool State via URL Hash Alone -- Designing 'Recipe URLs'

tommy — Sat, 07 Mar 2026 22:13:04 +0000

Ever been in this situation?

"Hey, can you check this Base64-decoded result for me?"

You paste a Base64 string into Slack, tell your teammate "decode this and look at the output." They open a decoder, paste the string, hit decode. Three steps just to share a single transformation result.

What if sending a URL instantly reproduced the same tool in the same state?

https://base64.puremark.app/#d=SGVsbG8sIFdvcmxkIQ%3D%3D&m=encode

Open that link and a Base64 tool launches in Encode mode with "Hello, World!" already entered and the encoded result displayed.

I call this pattern a "Recipe URL." This article walks through the design decisions and implementation.

Try it yourself -- go to PureMark Base64, encode something, and hit "Share." A Recipe URL is generated and copied to your clipboard.

What You'll Learn

A design pattern for encoding tool state into URL hashes
How to Base64-encode Unicode strings in a URL-safe way
A serverless architecture for state sharing
Concrete implementation code in React + TypeScript

Prerequisites

Basic TypeScript / React knowledge
Understanding of URL structure (hash, search params)

Why URL Hash?

It's never sent to the server

The hash portion of a URL (everything after #) is not included in HTTP requests. This is defined in the RFC.

https://example.com/path?query=value#fragment
                                      ^^^^^^^^
                                      Never sent to the server

This means user data never touches a server. Period.

For web tools, whether input data gets sent to a server is a critical privacy concern. With URL hashes, there's no data leakage path by design.

No URL shortener needed

A server-side approach (example.com/share/abc123) requires a backend with a database to store shared states. That means infrastructure to build and maintain.

The URL hash approach works on a fully static site. Cloudflare Pages or Vercel free tier -- no problem.

It's just a URL

A URL hash is part of a regular URL, so it works everywhere: Slack, Teams, email, GitHub issues. No special client required.

Recipe URL Design

Hash Parameter Structure

#d=<Base64-encoded data>&m=<mode>&o=<options>

Parameter	Content	Required
`d`	Input data (Base64-encoded)	Yes
`m`	Mode (`encode`, `decode`, `format`, etc.)	Yes
`o`	Tool-specific options (Base64-encoded JSON)	No

We use URLSearchParams directly. No custom parser needed.

Size Limit

Browser and proxy URL length limits vary, but in practice 2,000 characters is a safe upper bound. If the hash exceeds this, show an error to the user.

const MAX_HASH_LENGTH = 2000;

If you eventually need to handle larger data, you could compress with pako before Base64-encoding. But for now, simplicity wins.

Implementation

Unicode-Safe Base64 Encoding

btoa() only handles the Latin-1 range (0x00--0xFF). Pass a Unicode string and you get InvalidCharacterError:

btoa("Hello"); // Works fine
btoa("some unicode text"); // Might throw InvalidCharacterError

The solution: convert to UTF-8 bytes via encodeURIComponent before passing to btoa:

/** Unicode-safe Base64 encode */
function toBase64(str: string): string {
  return btoa(
    encodeURIComponent(str).replace(
      /%([0-9A-F]{2})/g,
      (_, p1) => String.fromCharCode(parseInt(p1, 16))
    )
  );
}

/** Unicode-safe Base64 decode */
function fromBase64(b64: string): string {
  return decodeURIComponent(
    Array.from(atob(b64), (c) =>
      '%' + c.charCodeAt(0).toString(16).padStart(2, '0')
    ).join('')
  );
}

How it works:

Encode:
  "Hello, World!"
  -> encodeURIComponent -> "Hello%2C%20World!"
  -> convert %XX to bytes -> binary string
  -> btoa -> Base64 string

Decode:
  Base64 string
  -> atob -> binary string
  -> each byte to %XX format -> "Hello%2C%20World!"
  -> decodeURIComponent -> "Hello, World!"

You could also use TextEncoder / TextDecoder, but the approach above is shorter and has broader browser compatibility.

Encode / Decode Functions

export interface RecipeState {
  data: string;
  mode: string;
  options?: Record<string, unknown>;
}

export function encodeRecipeHash(
  data: string,
  mode: string,
  options?: Record<string, unknown>,
): string | null {
  const params = new URLSearchParams();
  params.set('d', toBase64(data));
  params.set('m', mode);
  if (options && Object.keys(options).length > 0) {
    params.set('o', toBase64(JSON.stringify(options)));
  }
  const hash = params.toString();
  if (hash.length > MAX_HASH_LENGTH) return null;
  return hash;
}

export function decodeRecipeHash(hash: string): RecipeState | null {
  try {
    const clean = hash.startsWith('#') ? hash.slice(1) : hash;
    if (!clean) return null;
    const params = new URLSearchParams(clean);
    const d = params.get('d');
    const m = params.get('m');
    if (!d || !m) return null;
    return {
      data: fromBase64(d),
      mode: m,
      options: params.has('o')
        ? JSON.parse(fromBase64(params.get('o')!))
        : undefined,
    };
  } catch {
    return null;
  }
}

Key design choices:

encodeRecipeHash returns null when exceeding the 2,000-character limit (caller shows an error)
decodeRecipeHash never throws -- it returns null for any malformed input (safe even if someone hand-edits the URL)

Generating and Copying the Share URL

export async function copyShareUrl(
  data: string,
  mode: string,
  options?: Record<string, unknown>,
): Promise<boolean> {
  const hash = encodeRecipeHash(data, mode, options);
  if (!hash) return false;
  const url = `${window.location.origin}${window.location.pathname}#${hash}`;
  try {
    await navigator.clipboard.writeText(url);
    return true;
  } catch {
    return false;
  }
}

Using window.location.origin means it works seamlessly in both development (localhost:5173) and production (base64.puremark.app).

Using It in React Components

Restoring state on page load:

useEffect(() => {
  const recipe = getRecipeFromUrl();
  if (recipe) {
    setInput(recipe.data);
    setMode(recipe.mode as Mode);
    trackShareUrlOpen('base64');
    restoredFromRecipe.current = true;
  }
}, []);

The restoredFromRecipe flag prevents the clipboard auto-read feature (zero-click) from overwriting data that was shared via a Recipe URL.

Share button:

function ShareButton({ data, mode }: ShareButtonProps) {
  const [copied, setCopied] = useState(false);

  const handleShare = async () => {
    const ok = await copyShareUrl(data, mode);
    if (ok) {
      setCopied(true);
      setTimeout(() => setCopied(false), 2000);
    }
  };

  return (
    <button onClick={handleShare}>
      {copied ? 'Copied!' : 'Share'}
    </button>
  );
}

See this in action -- go to PureMark JSON Formatter, format some JSON, and hit the "Share" button. A Recipe URL is generated and ready to send.

Cross-Tool Linking

Here's where Recipe URLs get really interesting: passing data between tools.

For example, when the Base64 tool decodes something and detects it's JSON:

const openInJsonFormatter = () => {
  const hash = encodeRecipeHash(output, 'format');
  if (!hash) return;
  window.open(`https://json.puremark.app/#${hash}`, 'puremark-json');
};

Click "Open in JSON Formatter" and the JSON Formatter opens with the decoded result already formatted. No copy-paste needed.

Data flow:

Base64 Decoder (base64.puremark.app)
  -> Detects decoded output is JSON
  -> Shows "Open in JSON Formatter" button
  -> Click
  -> Opens json.puremark.app/#d=<JSON>&m=format
  -> JSON Formatter displays formatted result

Data flows between tools on different subdomains, mediated only by a URL hash. No backend. No API.

Summary

Recipe URLs encode tool state into URL hashes, enabling serverless state sharing
encodeURIComponent + btoa safely handles Unicode strings in Base64
URLSearchParams handles parsing -- no custom parser needed
A 2,000-character limit keeps URLs practical, with explicit errors when exceeded
The same pattern enables cross-tool linking -- passing data between independent tools via URL

This pattern applies to any static web app where you want to share input state: playgrounds, converters, formatters, calculators. If your tool has state worth sharing, Recipe URLs are a zero-infrastructure way to make it happen.

See Recipe URLs in action: PureMark Base64 / PureMark JSON Formatter -- decode Base64, detect JSON, and hand it off to the formatter with one click.

References

PureMark Base64 Encoder/Decoder -- Recipe URLs in production
PureMark JSON Formatter -- Cross-tool linking with Base64
MDN: URL - hash -- URL hash specification
MDN: btoa() -- Base64 encoding constraints

Forem: tommy

I Built a Skitch Alternative 2 Months Ago. It Now Has Twice the Tools.

What I Added

What Google Search Console Taught Me

iPhone Images Went from 5MB to 800KB

Android Camera OOM'd

Undo Almost Killed It

2 Months in Numbers

Beyond "There's No Pen"

References

I Added 5 Drawing Tools to My Canvas App. Undo Almost Killed It.

The Pen Was Jagged

The Marker Got Darker When Overlapped

Undo Almost Killed the Tab

Before / After

References

The Day Skitch Stopped Working — Which Screenshot Annotation Tool Should You Use in 2026?

A Decade of "Just Adding Arrows" — Gone

I Couldn't Justify $39/Year for Snagit

I Spent a Week Trying Every Alternative

CleanShot X ($29 one-time / macOS only)

Shottr (Free / macOS only)

ShareX (Free & Open Source / Windows only)

Flameshot (Free & Open Source / Cross-platform)

Lightshot (Free / Win & Mac)

The "No Install" Approach

Before / After

Comparison Table

Takeaway

References

How I Grew My Developer Tool Suite to 175 MAU in 3 Weeks — Zero Ad Spend, Articles Only

"Nobody's Coming" Is the Worst Part

What I Built: 7 Tools, One Umbrella

All the Numbers

MAU Growth

By Channel

What Worked #1: Designing Articles as SEO Machines

One Article = One Problem, Not One Tool

Failure Stories Get Likes. Tutorials Don't.

What Worked #2: Making Tools "Refer" Each Other

What Flopped — Spectacularly

Show HN → Zero

Share URL Feature → 4 Weeks at 0% Usage

X (Twitter) → Invisible

Design Decisions That Mattered

"Everything Runs Locally" Pays Off Slowly

KPI Dashboard Before Tools

3-Week Takeaways

Worked

Didn't Work

Still Unknown

Before / After

Do You Know Where Your JWT Goes When You Paste It Into an Online Tool?

The Moment I Froze

It's Already Happening — Data Leaks Via Online Tools

80,000 AWS Keys Leaked (November 2025)

Samsung ChatGPT Incident (March 2023)

The Structural Problem

Everything Could Run Client-Side

JSON Formatting: Done in 2 Lines

Base64: Browser Native API

JWT: Just Base64 Decode

Diff: 130-Line Custom Implementation

What Went Wrong Without a Server

Myers Diff Off-by-One Bug

2000-Character URL Limit

SEO Disadvantage

Why I Still Choose Client-Side

Before / After

Related Articles

References

What If the Page Could Detect Data Formats Without Copying? — Adding Page Scan + JWT Detection to a Chrome Extension

The Limits of Clipboard Detection

What Changed in v1.2.0

1. Inline Preview

2. Page Scan

3. JWT Detection

Content Script Blew Up on import

The Smart Quote Battle

"Hello World" Detected as Base64

Content Script Blew Up on `import`

Trap 1: `atob()` Doesn't Work

UTF-8 Support: Enter `TextDecoder`

Landmine 1: `new Date(1709654400)` Returns 1970