DEV Community: Andrew Rozumny

You’re probably leaking sensitive data every time you use online dev tools

Andrew Rozumny — Tue, 07 Apr 2026 10:46:31 +0000

Most developers don’t think twice before pasting data into online tools.

JSON formatters, JWT decoders, base64 converters, regex testers…

You just open a site, paste your data, get the result, and move on.

But here’s the problem:

You’re often sending that data to someone else’s server.

The hidden risk

That “quick utility” you’re using?

It might:

log your data
store it temporarily
or even keep it longer than you expect

And most of the time, you have no idea.

No clear guarantees.
No visibility.
No control.

“It’s just a formatter” — is it?

Even simple tools usually work like this:

You paste your data
It gets sent to a backend
The server processes it
You get a response

That means your data leaves your machine.

Sometimes it’s harmless.

Sometimes it’s not.

Where this becomes a real problem

Think about what developers actually paste into these tools:

API keys
tokens
internal JSON payloads
logs with user data
config files

Stuff that was never meant to leave your environment.

I caught myself doing this

At some point I realized I was doing exactly this.

Copy → paste → convert → done.

Without even thinking about where that data goes.

That’s when it started to feel… wrong.

A better approach

I started looking for tools that:

run entirely in the browser
don’t send data anywhere
don’t require accounts

Just open → use → close.

Why this matters

For small utilities, there’s no real reason to involve a server.

Formatting, encoding, decoding — all of this can be done locally.

Faster.
Safer.
Simpler.

What I ended up doing

I started putting together my own small set of browser-based tools.

Mostly for myself at first.

Just to avoid jumping between random sites and wondering what happens to my data.

For small tools, local-first just makes more sense.

Curious how you handle this

Do you trust online tools with sensitive data?

Or do you prefer local-first alternatives?

Stop Pasting Sensitive Data Into Random Online Tools

Andrew Rozumny — Fri, 03 Apr 2026 19:09:16 +0000

If you've ever pasted sensitive data into an online tool…

pasted a JWT into a random decoder
formatted JSON with API keys inside
tested regex on production data

…you’ve probably thought:

“this is probably fine”

But is it?

The uncomfortable truth

Most online tools still work like this:

You paste your data
It gets sent to a server
It gets processed there

And you're just… trusting it.

No idea where it goes.
No idea if it’s logged.
No idea who can access it.

The moment it hit me

I was debugging a JWT with user data inside.

Pasted it into a tool.

Then realized:

I have no idea where this just went.

That was enough.

So I built my own tools

I ended up building a set of dev tools that:

run entirely in the browser
don’t upload anything
don’t track anything

👉 https://tooldock.org/

Why this actually matters

This isn’t paranoia.

This is everyday dev stuff:

tokens
logs
internal payloads
user data

You don’t always control what ends up in your clipboard.

Example

Let’s say you’re:

decoding a JWT
formatting JSON
testing regex

With most tools:
→ your data leaves your device

With ToolDock:
→ everything stays local

Unexpected benefit

It’s not just privacy.

It’s speed.

no network
no waiting
instant feedback

Once you use client-side tools, everything else feels slow.

What’s inside

Right now there are ~90 tools:

JSON Formatter
Regex Tester (real-time)
UUID Generator
Base64 Encode / Decode
JWT Decoder
Timestamp Converter
Hash Generator

Curious

Do you actually care if tools upload your data?

Or is it “meh as long as it works”?

Every Stripe test card you'll ever need (plus fake checkout data for Shopify, WooCommerce & Magento)

Andrew Rozumny — Wed, 01 Apr 2026 23:14:29 +0000

If you're building or testing an e-commerce checkout, you've been there: opening the Stripe docs, scrolling for the right test card, copying it, then hunting for a fake address that matches the right country format.

I got tired of this. So I built a tool that generates everything at once.

But first — here's the complete reference you came for.

Stripe test cards

Success scenarios:

Card number	Type	Scenario
4242 4242 4242 4242	Visa	Success
5555 5555 5555 4444	Mastercard	Success
3782 822463 10005	Amex	Success
6011 1111 1111 1117	Discover	Success

Failure scenarios:

Card number	Scenario
4000 0000 0000 0002	Always declined
4000 0000 0000 9995	Insufficient funds
4000 0000 0000 0069	Expired card
4000 0000 0000 0127	Incorrect CVC
4000 0000 0000 0119	Processing error

3DS scenarios:

Card number	Scenario
4000 0025 0000 3155	3DS required
4000 0027 6000 3184	3DS recommended
4000 0000 0000 3220	3DS2 required

Use any future expiry date and any 3-digit CVV (4 digits for Amex).

Shopify Bogus Gateway

Shopify has a built-in test payment provider that doesn't need a real Stripe account.

Setup: Settings → Payments → Add payment method → Search "Bogus Gateway"

Card number	Result
1	Successful payment
2	Failed payment
3	Gateway exception

Use any name, any future expiry, any CVV.

WooCommerce test cards

WooCommerce with Stripe plugin uses standard Stripe test cards above.

Enable test mode: WooCommerce → Settings → Payments → WooCommerce Payments → Enable test mode.

Magento test cards

Magento 2 with Braintree sandbox:

Card number	Type
4111 1111 1111 1111	Visa
5500 0055 5555 5559	Mastercard
3714 496353 98431	Amex

CVV: 123, Expiry: any future date.

The part nobody talks about: fake addresses

Cards are easy. But you also need a realistic fake address that matches the country format — especially if your checkout validates postal codes.

US:

123 Main Street, Chicago, IL 60601

UK:

42 High Street, London, E1 2AB

Germany:

Hauptstraße 15, 10115 Berlin

Generating these manually every time is annoying.

Quick tips for checkout testing

Test the full flow, not just payment.
Most devs only test success. Your declined card handling is just as important — test that the error message is clear and the user can retry.

Always test 3DS separately.
3DS authentication adds a second step. Use card 4000 0025 0000 3155 to trigger it and make sure your UI handles the redirect correctly.

Test with guest checkout AND logged-in user.
These often have different code paths and different bugs.

The tool I built

I put all of this into one place — a free browser-based generator that gives you fake customer name, email, phone, country-specific address, and the right test card for your platform in one click.

Supports: Generic/Stripe, Shopify, WooCommerce, Magento, BigCommerce.
Countries: US, GB, AU, CA, DE, UA, JP.
Export as JSON or copy individual fields.

👉 tooldock.org/tools/ecommerce-test-data

Everything runs in your browser — nothing is sent to any server.

What's the most annoying part of checkout testing for you?

Claude AI Usage by Country: Israel Leads at 4.90x, Tanzania at 0.03x

Andrew Rozumny — Wed, 01 Apr 2026 21:47:53 +0000

Anthropic just released the Claude AI Usage by Country data via the
Anthropic Economic Index (sample: Nov 13–20, 2025).

The metric is simple: a score above 1x means a country's share of
Claude usage exceeds its share of the global working-age population.

🏆 Top performers

Country	Score
🇮🇱 Israel	4.90x
🇸🇬 Singapore	4.19x
🇨🇭 Switzerland	3.21x
🇰🇷 South Korea	3.12x
🇦🇺 Australia	3.27x
🇺🇸 USA	3.69x
🇨🇦 Canada	3.15x

📉 Lowest usage

Country	Score
🇹🇿 Tanzania	0.03x
🇲🇬 Madagascar	0.07x
🇲🇿 Mozambique	0.13x

What's interesting

Europe is surprisingly strong — France (2.66x), UK (2.59x), Ireland (2.39x), Norway (2.43x). Even countries like Poland (1.41x) and Greece (1.21x) are above baseline.
Asia is split — Singapore (4.19x) and South Korea (3.12x) are crushing it, while India (0.22x) and Indonesia (0.48x) are far below 1x.
Africa and Latin America are mostly sub-1x — likely a mix of pricing, language support, and infrastructure.
Japan at 1.59x — higher than I expected given the strong local AI ecosystem (Claude competes with domestic models there).

My take

The correlation seems to be: **English proficiency + tech sector density

GDP per capita**. Israel's dominance makes sense — massive tech industry, high English fluency, small population (so the ratio amplifies easily).

The really interesting story is what happens as Claude adds more
languages and local pricing — countries like Brazil (0.70x) and Mexico
(0.44x) feel like huge untapped markets.

Source: Anthropic Economic Index. Data as of Jan 15, 2026.

What's your country's score? Did anything surprise you?

English is now a programming language and I have mixed feelings

Andrew Rozumny — Sun, 29 Mar 2026 10:53:43 +0000

A few years ago if you said "just describe what you want and the computer will do it" — that was science fiction. Now it's Tuesday.

I spent last week building 40 browser-based developer tools. Half of them I described in plain English to Claude Code and it just... built them. Components, types, tests, the lot.

The weird part isn't that it works. It's how it feels.

There's this guilt developers know — the "am I even really coding?" feeling. Stack Overflow used to trigger it. AI just cranks it to 11.

But here's what I actually noticed: the thinking didn't go away. It moved. Less time on "how do I type this correctly". More time on "is this the right thing to build at all".

The English-as-code thing is real. But it's less like replacing programming and more like the abstractions keep going up. Assembly → C → Python → now this. Each step felt like cheating to someone.

Where do you draw the line between "using tools" and "not really coding"? Or is that even the right question?

I added 40 tools to my dev toolkit site in one week — here's what I learned

Andrew Rozumny — Sat, 28 Mar 2026 19:42:40 +0000

A week ago ToolDock had 20 tools. Today it has 60+.

Here's what I shipped, what broke, and what actually matters.

What I built

All tools run entirely in your browser. No sign-up, no server round-trips, no data leaves your device.

This week I added:

AI & LLM tools

Token Counter — count tokens before sending to GPT/Claude
LLM Cost Calculator — compare API costs across providers
MCP Config Generator — generate Claude Code config files
Cursor Rules Generator — .cursorrules for your stack
System Prompt Builder — templates for any LLM

CSS & Styling

CSS ↔ Tailwind converter
SCSS/LESS compilers (browser-based, no Node needed)
Tailwind CSS Cheatsheet with rem/px display

Developer utilities

.gitignore Generator
.env File Validator
Image Converter (PNG/WebP/JPEG, multi-upload)
Word Counter with Flesch reading score
chmod Calculator
JSONPath Tester
OpenAPI Spec Validator

What I learned

1. Browser APIs are more powerful than most developers realize

SHA-256 hashing, image conversion, SCSS compilation — all running client-side with zero dependencies.
Web Crypto API, Canvas API, and WebAssembly make things possible that seemed server-only two years ago.

2. Default values matter more than features

Tools with pre-filled examples get used immediately.
Tools with empty inputs get closed immediately.
Every single tool now has real, meaningful default data.

3. Tool chaining changes how people work

Added a "Send to →" feature that pipes output from
one tool directly into another. YAML → JSON Formatter
→ JSON Validator in one click.
People stay on the site 3x longer when they chain tools.

4. Smart Paste is underrated

Paste anything — JWT, JSON, SQL, cURL command,
Base64 string — and the site auto-detects the format
and opens the right tool. Sounds simple, surprisingly
useful in practice.

What's next

Still broken: LESS → Tailwind mapping (partial output)
Still ugly: Crontab Generator UI
On the list: JSON Schema from TypeScript,
HTTP Headers Reference,
More AI-powered explanations

Link: tooldock.org

What tools do you reach for daily that aren't there yet?

Your framework choice is now your biggest AI cost lever

Andrew Rozumny — Fri, 27 Mar 2026 11:01:14 +0000

The Wasp team published something worth reading today — they gave
Claude Code the exact same feature prompt for two identical apps, one in Next.js and one in Wasp, and measured everything.

The numbers:

Metric	Wasp	Next.js
Total cost	$2.87	$5.17
Total tokens	2.5M	4.0M
API calls	66	96
Output tokens (code written)	5,416	5,395

The last row is the interesting one. The AI wrote almost exactly
the same amount of code. But it cost 80% more to do it in Next.js.

The reason: cache creation and cache reads. Every LLM call re-reads the codebase context from scratch. A bigger codebase means every single turn costs more — not just for reading, but for loading into cache in the first place.

Next.js cache creation was 113% more expensive. Not because the AI did more. Because it had more boilerplate to read before it could start.

What this actually means

We've been evaluating frameworks on DX, performance, and ecosystem.
Add a new one: context efficiency.

How much of an AI's context window goes to signal (your business logic) vs noise (framework boilerplate)?

Wasp's declarative config means auth, routing, and jobs are defined in ~10 lines. Next.js equivalent is spread across middleware, route handlers, session files, and API directories. Same result, 4x the tokens.

The compounding problem

This test was a single feature. Real apps accumulate features. Every new route, every new model, every new API handler adds to the context that gets re-read on every single LLM call.

The performance degradation isn't linear either — research shows that AI performance degrades well before the context window fills.
You're not just paying more per call, you're getting worse output.

What to do about it

Measure your codebase token count now.
Run: find . -name "*.ts" -o -name "*.tsx" | xargs wc -c
That's roughly your AI cost baseline.
Audit your boilerplate ratio.
How much of that is business logic vs glue code?
The higher the glue ratio, the worse your AI economics.
Consider framework choices through this lens.
Wasp, Rails, Laravel — highly opinionated frameworks
have a new advantage they didn't have 2 years ago.
Less boilerplate = cheaper AI = faster iteration.

The irony

The same properties that make a codebase easy for humans to navigate — explicit, verbose, self-documenting — are exactly what's expensive for AI. The abstractions we used to see as "magic" are now genuinely economical.

I've been thinking about this for ToolDock — a browser-based
dev tools platform I'm building. Every tool page is pure business logic with almost no framework boilerplate, because everything runs statically. The AI token efficiency on it is noticeably better than client projects I've worked on with heavier stacks.

Worth checking the full Wasp post for the methodology details — they open-sourced both apps and the measurement scripts, which is the right way to publish a benchmark.

What's your current codebase token count?

I got tired of pasting sensitive strings into random websites, so I built a browser-based hash generator

Andrew Rozumny — Tue, 24 Mar 2026 15:49:44 +0000

I work on a few different projects and I hash things constantly —
checking file integrity, debugging password logic, verifying API payloads. For a long time I just googled "md5 generator" or "sha256 online" and used whatever came up first.

Then one day I actually looked at one of those tools in DevTools. The input was being sent to a server on every keystroke. For MD5 it probably doesn't matter. But I sometimes paste things that are closer to sensitive — partial tokens, config values, test passwords.
That felt dumb.

So I built my own.

How it works

The SHA family (SHA-1, SHA-256, SHA-512) is natively supported
in the browser via the Web Crypto API:

async function sha256(message) {
  const msgBuffer = new TextEncoder().encode(message);
  const hashBuffer = await crypto.subtle.digest('SHA-256', msgBuffer);
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}

No libraries, no server calls. Just built-in browser APIs.

MD5 isn't part of Web Crypto (it's considered cryptographically broken, so intentionally excluded), so I inlined a pure-JS implementation — no npm package, no external requests.

What I actually use it for

File checksums — when I download something and the provider
lists a SHA-256 hash, I drop the file in and verify it matches. Takes 2 seconds.

Debugging auth logic — when something in a login flow isn't working and I want to check what hash my backend is actually generating vs what I expect.

Comparing API responses — quick way to check if two payloads are identical without reading them character by character.

It's part of a bigger thing

I've been building ToolDock — a set of browser-based dev tools I keep open in a pinned tab. JWT decoder, JSON formatter, Base64, regex tester, UUID generator and now hash generator.

Everything runs locally. No sign-up, no tracking, no server round-trips. I built it because I wanted tools I could actually trust with real data.

The hash generator is at https://tooldock.org/tools/hash-generator
if it's useful to you. Feedback welcome — especially if there's an algorithm you need that's missing.

What do you use for quick hashing during development?

Why I built my own browser-based dev tools (and why privacy matters more than I thought)

Andrew Rozumny — Sat, 21 Mar 2026 19:31:24 +0000

I've been a developer for years. Like most people, I had a handful of online tools I used daily — JWT decoders, JSON formatters, Base64 encoders. Open a tab, paste, copy, close.

Then one day I caught myself pasting a production API token into some random website I'd never heard of.

I didn't know who built it. I didn't know where my data went. I just trusted it because it showed up in Google search results.

That bothered me enough to build something better.

What I built

ToolDock is a collection of developer tools that run entirely in your browser. No backend, no accounts, no data sent anywhere. You can verify this yourself — open DevTools Network tab while using any tool and you'll see zero outbound requests with your data.

Current tools:

JWT Decoder
Base64 Encode/Decode
JSON Formatter + Validator
Regex Tester
CRON Expression Parser
Color Converter (HEX ↔ RGB ↔ HSL ↔ HSB)
UUID Generator, Text Diff, Timestamp Converter
and more (19 total)

What I learned building it

Browser APIs are powerful enough for almost everything. JWT decoding, Base64, regex testing, color conversion — none of this needs a server. We just got used to sending data somewhere because it was easier to build that way.

Privacy as a feature actually resonates.
When I tell developers "your JWT never leaves your browser", I see immediate understanding. They've had the same paranoid moment I had.

SEO for tools is different from SEO for content.
Each tool is essentially a landing page for a specific search query. "JWT decode online", "Base64 encoder browser" — these have real search volume and your tool page is the answer.

What's next

Adding 2-3 new tools every week. Hash generator, Markdown previewer, Number base converter are next.

If you want to check it out: tooldock.org

And if there's a tool you wish existed as a private browser-based version — I'd genuinely love to hear it in the comments.

Built with Next.js + TypeScript + Tailwind,
deployed on Vercel. Happy to answer any
technical questions.