DEV Community: Ryan Caldwell

9 CSS Generators in One Place — Because I Had 9 Different Bookmarks and That's Ridiculous

Ryan Caldwell — Mon, 06 Apr 2026 05:26:33 +0000

I had a bookmark folder called "CSS Generators" with nine links in it.

One for flexbox layouts. One for grid. One for box shadows. One for glassmorphism. One for animations. One for clip-path shapes. One for loaders. One for text shadows. One for border radius.

Nine different sites, nine different interfaces, nine different levels of ad intensity. I couldn't even remember which bookmark was which anymore — I'd click three wrong ones before finding the box shadow generator.

So I put them all in one place.

The Generators

Anytools.io/design — all nine, same interface, same workflow:

1. CSS Flexbox Generator

Visual builder for flexbox layouts. Set flex-direction, justify-content, align-items, flex-wrap, and gap using controls instead of typing CSS from memory. Add child items, adjust their individual flex-grow, flex-shrink, flex-basis, order, and align-self. Live preview updates as you click. Copy the generated CSS when you're happy.

When I use it: Prototyping navigation bars, card layouts, centering things (yes, still).

2. CSS Grid Generator

Define rows, columns, gaps, and named areas visually. Drag to create grid areas, set explicit track sizes (fr, px, %, auto, minmax), configure justify-items and align-items. The preview shows the actual grid lines so you can see exactly what you're building.

When I use it: Dashboard layouts, magazine-style content grids, anything with more than two dimensions of layout control.

3. Box Shadow Generator

Multi-layer shadow editor with real-time preview. Add multiple shadows, adjust offset-x, offset-y, blur, spread, and color for each layer independently. Supports inset shadows. The preview shows shadows against your chosen background color so you can see how they'll actually look.

When I use it: Card elevation effects, subtle depth on buttons, neumorphism experiments.

4. CSS Animation Generator

Build keyframe animations without writing @keyframes by hand. Set animation properties (duration, timing-function, delay, iteration-count, direction, fill-mode), define keyframe steps visually, and preview the animation in real time. Generates both the @keyframes block and the animation shorthand.

When I use it: Loading states, hover transitions, entrance animations, attention-grabbing UI elements.

5. Glassmorphism Generator

The frosted-glass effect that's everywhere right now. Adjust backdrop-filter: blur(), background opacity, border, and border-radius. Preview against a background image so you can see the actual frosted glass effect, not just a semi-transparent box.

When I use it: Modal overlays, floating cards, hero section overlays, navigation bars.

6. CSS Loader Generator

Animated loading spinners and progress indicators, pure CSS. Multiple loader styles — spinners, dots, bars, rings, pulses. Customize colors, size, and speed. Copy a single block of CSS + HTML.

When I use it: Loading states while data fetches, skeleton screens, form submission indicators.

7. Clip-Path Generator

Custom shapes with a visual polygon editor. Click to add points, drag to adjust, and see the shape update in real time. Includes presets for common shapes (triangle, pentagon, star, arrow) as a starting point. Generates the clip-path: polygon() value.

When I use it: Hero image masks, decorative section dividers, creative image framing.

8. Text Shadow Generator

Layered text shadows with preview. Add multiple shadow layers, adjust offset, blur, and color for each. Preview on different background colors and font sizes to see how the shadow reads at various scales.

When I use it: Headings over images, retro text effects, subtle depth on light backgrounds.

9. Border Radius Generator

Asymmetric rounded corners — because border-radius: 10px isn't always what you want. Control all eight values independently (each corner has a horizontal and vertical radius) using sliders. The preview shows the exact shape you're creating.

When I use it: Organic shapes, blob-like containers, creative button designs.

Also on the Design Page

The CSS generators sit alongside a bunch of other design tools:

Color Palette Generator — generate harmonious palettes from a base color
Gradient Generator — linear, radial, and conic gradients with unlimited color stops
Contrast Checker — WCAG AA/AAA compliance for text/background combinations
Tints & Shades Generator — produce 10 tints and 10 shades of any color
Type Scale Generator — modular type scales for consistent typography
Font Pair Suggestions — Google Fonts pairings that work together
SVG Optimizer — compress SVGs by removing unnecessary metadata
Favicon Generator — create favicons from text, emoji, or uploaded images

Why One Site Instead of Nine

Three reasons:

1. Consistent interface. Every generator works the same way: adjust controls on the left, see preview on the right, copy code at the bottom. No relearning a new UI every time I switch tools.

2. No context switching. When I'm building a card component, I might need box shadow, border radius, AND glassmorphism. Having them in the same place means I stay in flow instead of tab-hopping.

3. No friction. No sign-ups, no "pro tier" for the good features, no cookie consent banners covering half the screen. The generators just work.

Everything runs client-side in the browser. No data sent anywhere. Anytools.io is free and has 89 tools total across dev, design, calculators, and health/fitness.

Which CSS property do you find yourself reaching for a generator most often? I'm always looking to add more tools — the clip-path generator was actually a user request.

I Got Tired of Opening 5 Different Sites to Plan My Nutrition — So I Built One Free Hub

Ryan Caldwell — Mon, 06 Apr 2026 05:24:09 +0000

I'm a web developer who also happens to care about fitness. And something has bugged me for years.

Every time I want to recalculate my nutrition plan, I open five different websites:

One for TDEE
One for macros
One for calorie deficit targets
One for protein intake
One for body fat percentage

Half of these sites now require an account. Most are drowning in ads. A couple have started paywalling features that used to be free — for running a math formula.

These are calculators. They take numbers in and spit numbers out. There is no reason they need an account, an app download, or a subscription.

So I built all of them into one place.

14 Free Health & Fitness Calculators

Anytools.io/health — everything in one spot, zero friction:

For Nutrition Planning

TDEE Calculator — Uses the Mifflin-St Jeor equation (the most accurate BMR formula according to the Academy of Nutrition and Dietetics). Enter your stats, get maintenance calories plus targets for weight loss and gain.
Macro Calculator — Protein, carbs, and fat split based on your specific goal: weight loss, maintenance, muscle gain, or custom ratios.
Calorie Deficit Calculator — Set your target weight, get the daily deficit needed, and see a realistic timeline.
Protein Intake Calculator — Based on body weight and activity level. Shows the range recommended by current sports nutrition research.

For Training

Heart Rate Zone Calculator — Uses the Karvonen method (based on heart rate reserve), which is significantly more accurate than the generic 220-minus-age formula. Shows all five training zones with target ranges.
One Rep Max Calculator — Enter your working weight and reps, get estimated 1RM using three different formulas (Epley, Brzycki, Lombardi) so you can compare.
Pace Calculator — For runners: enter any two of distance, time, and pace to calculate the third. Includes race time projections for 5K, 10K, half marathon, and marathon.
VO2 Max Estimator — Estimates aerobic fitness level based on your running performance.

For Body Composition

Body Fat Calculator — US Navy method using simple tape measurements. No calipers needed.
Ideal Body Weight Calculator — Compares four different formulas (Devine, Robinson, Miller, Hamwi) side by side so you can see the range.
BMI Calculator — With context about what the number actually means and its limitations.

Other Tools

Water Intake Calculator — Based on body weight, activity level, and climate.
Sleep Calculator — Calculates optimal bedtimes based on 90-minute sleep cycles.
BAC Calculator — Blood alcohol content estimator.

Why I Built These as a Web Developer

I could have built a mobile app. But I didn't, for specific reasons:

No download friction. Nobody wants to install an app just to run a TDEE calculation once. A website you can bookmark works on every device, every platform, instantly.

Client-side processing. Every calculation runs in your browser. Your body measurements, weight, and health data never leave your device. I didn't want to build a tool that collects sensitive health data on a server — that's unnecessary for a calculator.

No accounts. There's nothing to sign up for because there's nothing to store. You enter numbers, you get results, you close the tab. If you want to recalculate in three months, you just come back.

No ads. The calculators are fast and clean because they don't need to load 47 ad scripts before showing you a number.

The Formulas Are Transparent

Something that bothers me about most online calculators: they don't tell you which formula they're using. You get a number with no context.

Every calculator on Anytools shows which equation it uses, cites the research behind it, and in several cases lets you compare multiple formulas side by side. The TDEE calculator uses Mifflin-St Jeor. The heart rate zones use Karvonen. The 1RM calculator shows Epley, Brzycki, and Lombardi simultaneously.

If you care about the math, it's there. If you don't, you still get accurate results.

What Else Is On the Site

The health calculators are part of a larger platform. Anytools.io also has:

26 developer tools — JSON formatter, JWT decoder, regex tester, Base64, password generator, etc.
24 design tools — Color palette generator, CSS generators (flexbox, grid, glassmorphism), contrast checker, etc.
16 calculators — Compound interest, loan, mortgage, tip, unit converter, etc.

Same principles everywhere: free, no accounts, client-side, no tracking.

If you use any of these calculators regularly, I'd genuinely like to know: what's the one fitness/nutrition calculator you wish existed but doesn't? I'm actively building new tools and user requests get prioritized.

12 Browser-Based Tools I Actually Use Every Day as a Developer

Ryan Caldwell — Fri, 03 Apr 2026 02:59:55 +0000

Every developer has a collection of browser tabs they keep returning to -- little utilities for formatting, encoding, converting, and debugging. Over the past year I've consolidated mine down to a single platform, and I want to share the tools I genuinely use on a daily or weekly basis. They all happen to live at anytools.io, they all run client-side in the browser, and none of them require an account.

This is not an exhaustive list. It is the subset I actually reach for during real work.

1. JSON Formatter & Validator

This is probably the tool I open most. Anytime I'm debugging an API response or reading a config file, I paste raw JSON in and get a clean, syntax-highlighted, collapsible tree view. It catches syntax errors instantly, which saves me from staring at a wall of text trying to find a missing comma.

When I use it: Inspecting API responses, validating config files, making nested JSON readable before sharing with teammates.

2. Base64 Encoder/Decoder

Working with auth tokens, data URIs, or encoded payloads -- Base64 shows up constantly. Instead of firing up a terminal and remembering the right flags for base64 on macOS vs. Linux, I just paste and convert.

When I use it: Decoding auth headers, encoding images for inline CSS, debugging encoded payloads in logs.

3. JWT Decoder

JWTs are everywhere in modern web apps, and being able to quickly peek at the header and payload without writing code is invaluable. This tool breaks a JWT into its three parts and displays them as readable JSON. Since it all runs in the browser, I don't worry about pasting tokens into some random website.

When I use it: Debugging authentication flows, verifying token claims and expiration times, checking which algorithm a token uses.

4. Regex Tester

Writing regex is one thing. Debugging regex is another. The regex tester lets me write a pattern, paste in test strings, and see matches highlighted in real time. It shows capture groups, explains what each part of the expression does, and flags common mistakes.

When I use it: Building validation patterns, parsing log files, writing search-and-replace patterns before running them on production data.

5. UUID Generator

Whenever I need unique IDs for test data, database seeds, or mock objects, I generate a batch of UUIDs here. It supports v4 (random) and lets you generate multiple at once.

When I use it: Seeding test databases, generating placeholder IDs for mock data, creating unique keys for configuration entries.

6. Timestamp Converter

Converting between Unix timestamps and human-readable dates is something I do more often than I'd like to admit. This tool converts both directions and supports multiple formats. It also shows "relative time" (e.g., "3 hours ago"), which is handy when digging through logs.

When I use it: Reading Unix timestamps in database records, debugging scheduled jobs, converting dates for API parameters.

7. Password Generator

For local dev environments, test accounts, and quick throwaway credentials, I use this to generate strong passwords with configurable length and character sets. It runs entirely in the browser using the Web Crypto API, so the generated passwords never touch a server.

When I use it: Setting up dev environment credentials, generating secrets for .env files, creating test user passwords.

8. Color Converter

Front-end work constantly requires jumping between HEX, RGB, HSL, and sometimes OKLCH. This tool converts between all of them and gives a live preview. I keep it open whenever I'm working on UI code.

When I use it: Converting design tokens between formats, adjusting colors for CSS, translating Figma color values to code.

9. Contrast Checker

Accessibility is not optional. The contrast checker takes two colors and tells you whether they pass WCAG AA and AAA standards for both normal and large text. I run every color combination through this before committing UI changes.

When I use it: Verifying text/background color combinations meet accessibility standards, checking hover and focus state contrast ratios.

10. URL Encoder/Decoder

Query strings with special characters, encoded redirect URIs, API parameters with spaces -- URL encoding issues are a daily occurrence. This tool handles encoding and decoding in both directions and is faster than trying to remember JavaScript's encodeURIComponent vs. encodeURI distinction.

When I use it: Debugging malformed URLs, encoding query parameters, decoding redirect URIs in OAuth flows.

11. Markdown Preview

When I'm writing README files, documentation, or blog posts (like this one), I want a live preview without spinning up a local dev server. This tool renders GitHub-flavored Markdown in real time as I type.

When I use it: Drafting README files, writing documentation, previewing markdown before committing.

12. Code Minifier

For quick one-off minification of JavaScript, CSS, or HTML snippets, this tool shrinks the code and shows you the size reduction. It is not a replacement for a proper build pipeline, but it is perfect for quick checks or inline scripts.

When I use it: Minifying inline scripts for email templates, quick size checks, compressing CSS snippets for embedded widgets.

Why These Over Alternatives?

There are hundreds of online developer tools. The reason I've settled on this particular set comes down to three things:

They are all in one place. I have one bookmark instead of twelve. The search function finds any tool instantly.
Client-side processing. My data stays in my browser. This matters a lot when I'm pasting JWTs, API responses, or anything that touches production data.
No friction. No sign-up, no cookie banners, no "upgrade to pro" modals. The tools just work.

If you spend time doing any of the tasks above, give anytools.io a look. And if you have a tool you wish existed but doesn't -- I'd genuinely like to hear about it in the comments.

The Case for Client-Side Developer Tools

Ryan Caldwell — Tue, 31 Mar 2026 04:28:02 +0000

Every time you paste a JWT into a decoder, run a regex against a sample string, or convert a color value from HSL to hex in an online tool, you're making a small architectural choice: where does the processing happen?

For most online tools, the answer is a server you don't control. Your input travels over the network, gets processed somewhere, and a result comes back. For a JWT decoder or a Base64 transformer, this is completely unnecessary. These are trivial operations. JavaScript can do them in microseconds, right there in the tab you already have open.

The fact that so many online tools send data to a server anyway is worth examining.

What "Client-Side" Actually Means

A client-side tool processes your input entirely within your browser. The JavaScript running on the page takes your input, transforms it, and produces output -- no network request, no server involved. Once the page has loaded, it could work without any internet connection at all.

This is distinct from tools that are served over the web but process data server-side. Both run in a browser. Only one keeps your data in your browser.

The distinction matters for a few reasons that are worth taking seriously.

The Privacy Argument Is Straightforward

When data doesn't leave your browser, it can't be logged, stored, analyzed, or leaked by a third party. This is a hard guarantee, not a policy promise.

A server-side tool can publish a privacy policy saying they don't log inputs. That policy can change. It can be violated. It can be irrelevant if the company is acquired, if a breach occurs, or if the policy language turns out to be narrower than it appeared.

Client-side processing eliminates this entire category of risk. There's no policy to trust because there's nothing to log. The data never left your machine.

For routine development work -- formatting some dummy JSON, generating a UUID, converting a timestamp -- the distinction feels academic. But habits transfer. The developer who builds a reflex of checking whether tools are client-side before using them is less likely to casually paste a production API key or a JWT with real user data into something that logs inputs.

The Performance Argument Is Underappreciated

Network latency is the dominant cost in web performance. Client-side tools eliminate that cost entirely for data processing operations.

Consider what happens when you type into a server-side formatting tool: your keystroke triggers an input event, the tool debounces for a moment, fires an HTTP request, waits for a round trip (even at 50ms that's a perceptible delay), and renders the result. For a simple operation like pretty-printing JSON, you're introducing network I/O where none is needed.

A client-side implementation of the same tool responds in single-digit milliseconds. The result updates as you type with zero perceptible lag. There's no debounce needed because there's no request to batch. The user experience is categorically better, and it's better for a fundamental reason: the architecture matches the problem.

Why Don't More Tools Work This Way?

A few reasons, some legitimate and some less so.

The legitimate reason: some tools genuinely require server-side processing. File conversion between complex formats, anything involving a library that doesn't have a JavaScript implementation, operations that would be computationally intensive enough to block the browser's main thread -- these have real reasons to use a server.

The less legitimate reasons are mostly historical and economic. Many developer tools were built before browser JavaScript was fast enough to handle non-trivial operations comfortably. Building a server-side tool also gives you a natural collection point for usage data and a potential conversion funnel into a paid product. Client-side tools are harder to monetize because users who never hit your servers are hard to track and harder to upsell.

This doesn't make server-side tools malicious. It explains why the default drifted in that direction even when the problem didn't require it.

The Browser Is More Capable Than Most Developers Use It For

Modern JavaScript is fast. WebAssembly makes it faster. The browser has access to cryptographic primitives, can handle file I/O through the File API, can run complex parsing operations, and can process data structures of meaningful size without breaking a sweat.

A well-built client-side tool can do essentially everything a server-side tool can do for the category of utilities developers actually use day-to-day: encoding, decoding, formatting, transforming, generating, validating, diffing, converting.

There's a reasonable argument that if a tool's only job is to transform text or structured data, and that transformation doesn't require external state or a resource that only exists server-side, then the tool should run in the browser. The server is a cost center in that architecture -- it adds latency, attack surface, operational overhead, and privacy risk for zero benefit.

This Is Worth Building For

I've been thinking about this problem for a while, which is part of why I built Anytools.io -- a collection of developer, designer, and calculator tools that process everything client-side. No accounts, no tracking, no requests going out when you paste something in. It's one implementation of this philosophy, but the broader point stands regardless of which tools you use.

The ecosystem of developer utilities has grown largely without thinking carefully about where processing should happen. Now that the browser is capable enough to handle it, and now that developers are (rightly) more privacy-conscious than they were ten years ago, client-side processing should be the default assumption for simple utility tools -- not the exception that requires explanation.

If you're building a tool for developers, start from the question: does this actually need a server? You might find the answer is no more often than you expected.

Why I Stopped Using 15 Bookmarked Tool Sites (And What I Do Instead)

Ryan Caldwell — Sat, 28 Mar 2026 04:51:44 +0000

At some point I looked at my "Dev Tools" bookmark folder and counted 23 entries.

JSON formatter. Base64 encoder. Base64 decoder (a different site, for reasons I no longer remember). UUID generator. Cron expression explainer. Color picker. Regex tester. Unix timestamp converter. Diff checker. JWT debugger. And on it went.

I had a bookmark for every problem I'd ever encountered and solved by finding a single-purpose website. The folder had become a graveyard of one-off solutions, most of which I'd used once and would probably never open again -- except I couldn't bring myself to delete them because what if I needed them?

This is bookmark bloat, and it's a quietly significant source of developer friction.

The Real Cost Isn't the Bookmarks

The problem isn't the folder getting long. The problem is what happens when you actually need a tool.

You're in the middle of something. You need to quickly decode a JWT or convert a timestamp. So you open a new tab, try to remember which bookmark it was, scan the folder, click the wrong one, close it, find the right one -- and by the time you're done, you've lost the thread of what you were actually working on.

Context switching is expensive. Anything that requires you to navigate, search, and orient yourself in a new environment has a cost, even if each individual instance feels trivial. Multiply that across a day of development work and it adds up.

The bookmark folder was supposed to solve the "I need a quick tool" problem. Instead it became its own navigation problem.

Why Single-Purpose Sites Proliferate

Every tool site starts as a solution to a real problem someone had. Someone needed a JSON formatter, built a clean one-page app, put it online. It ranks well for "json formatter online," gets bookmarked by thousands of developers, and becomes the canonical answer to that specific need.

The result is a fragmented ecosystem where each micro-problem has its own micro-solution, each with its own URL, its own UI conventions, its own load time, its own cookie banner.

There's nothing wrong with any individual tool in this ecosystem. The problem is accumulation. When you have 23 of them, the overhead of managing them starts to exceed the benefit.

What I Changed

I did a few things that genuinely helped.

I audited and deleted aggressively. I went through the bookmark folder and asked: have I used this in the last 90 days? For most of the 23 entries, the answer was no. I deleted them. If I turned out to need them again, I could find them again in ten seconds via a search. The cost of re-finding something is much lower than the cost of managing a folder of 23 things indefinitely.

I looked for tools that consolidated multiple utilities. Instead of a separate site for every transformation or formatting task, I looked for tools that handled a broad category in one place. If I can do JSON formatting, Base64 encoding, and timestamp conversion from the same interface, I only need to learn one URL and one UI.

I tested tools for client-side processing before bookmarking. I got burned once by a tool that was logging inputs. Now before anything gets a permanent bookmark, I check the network tab. Tools that process data locally in the browser get preference, both for privacy and for the practical benefit that they tend to be faster.

I stopped bookmarking things I'd only used once. If I used a tool once for a specific debugging session, I don't bookmark it. I might not ever need it again in exactly that form. If I do, the search is fast. Bookmarks are for things you return to regularly, not for archiving every tool you've ever touched.

The Folder Now Has Six Entries

Six tools I use regularly enough that having them one click away is worth it. Everything else I find as needed.

The six entries are consolidated tools -- each one covers a family of related tasks rather than a single operation. That covers about 80 percent of what I was previously using 23 bookmarks for.

The other 20 percent I just search for when I need it. The search takes five seconds. The mental overhead of maintaining a tidy, useful bookmark folder was taking much more than that.

If your dev tools bookmark folder has grown beyond what you can scan in a single glance, it's probably not helping you anymore. Prune it. You won't miss what you cut.

5 Things to Check Before You Paste Sensitive Data into Any Online Tool

Ryan Caldwell — Fri, 27 Mar 2026 06:56:01 +0000

You have a JWT that isn't decoding the way you expect. Or a Base64 string you need to inspect. Or a JSON blob from a production API response that you want to format.

The fastest thing to do is paste it into an online tool.

Most of the time this is fine. But sometimes it isn't -- and the difference matters, especially when the data you're pasting contains API keys, PII, internal infrastructure details, or anything you wouldn't want showing up in a server log somewhere.

Here's a checklist I go through before I paste anything remotely sensitive into an online tool.

1. Open the Network Tab First

Before you paste anything, open DevTools (F12) and go to the Network tab. Clear it, then paste your data into the tool and trigger the processing.

Watch what happens.

If the tool is genuinely client-side, you should see nothing -- or at most static asset requests. If you see an XHR or fetch request go out the moment you paste, your data just left your browser. That's not necessarily malicious, but it means you've handed your input to a server you know nothing about.

This one step catches a surprising number of tools that market themselves as "private" or "instant" but are quietly sending data back to a backend.

2. Check for HTTPS -- But Don't Stop There

HTTPS means the connection is encrypted in transit. It does not mean the server isn't logging your input. These are completely separate concerns.

A tool running over HTTPS can still store every paste in a database. Encryption in transit protects you from eavesdroppers on the network. It says nothing about what happens to your data once it arrives at the destination.

HTTPS is a baseline requirement, not a privacy guarantee.

3. Look at the Source or Check Their Privacy Policy

If a tool claims to be client-side, you can verify it. Right-click the page, view source, and look for any external API calls or server endpoints referenced in the JavaScript. If the tool is truly running in your browser, the processing logic will be right there in the JS -- readable, auditable, not hidden behind a server call.

For open-source tools, check the repo. For commercial tools, read the privacy policy and specifically look for language about logging, analytics, or data retention. Vague language like "we may collect usage data" is worth paying attention to.

4. Classify Your Data Before You Paste

Not everything deserves the same level of scrutiny. Build a quick mental model:

Low sensitivity: Random strings, dummy data, public documentation you're trying to format -- paste freely.
Medium sensitivity: Internal API responses with non-critical metadata, configuration files without credentials -- worth a quick check.
High sensitivity: JWTs with embedded user data, API keys, database connection strings, anything from a production environment -- treat these like passwords. Either use a local tool or sanitize the data before pasting.

The goal isn't paranoia. It's proportionality. Most of the time you're pasting something harmless. The problem is when habit overrides judgment on the one paste that actually matters.

5. Ask: Would This Tool Work Offline?

This is a useful heuristic. If a tool genuinely processes everything in the browser, it should work without an internet connection once the page has loaded.

Try disconnecting from the network (or throttling to offline in DevTools) and using the tool. If it breaks, it's talking to a server. If it still works, you have strong evidence that your data isn't leaving the browser.

This doesn't catch everything -- some tools work offline but still phone home when connected -- but combined with the Network tab check, it gives you a good picture.

The Defaults Aren't Always Safe

The broader issue is that developers are trained to reach for the fastest tool available, and the fastest tool available is usually whatever ranks highest in a Google search. Most of those tools are fine. But "fine" is doing a lot of work there.

A JSON formatter that logs every paste won't announce that fact. A Base64 decoder that sells usage data won't put it in the UI. The defaults favor convenience, not privacy.

None of this requires you to stop using online tools. It just requires thirty seconds of conscious evaluation before you paste anything you'd regret seeing in a breach notification.

The Network tab is always open. Use it.

JWT decoder tools: what's safe, what's sketchy, and what I actually use

Ryan Caldwell — Sat, 14 Mar 2026 06:26:30 +0000

You're probably fine. But let me explain why.

Every few months a thread pops up on Reddit or Slack: "Is it safe to paste my JWT into jwt.io?"

The honest answer is: it depends on the token, and most devs already know the safe answer but want confirmation.

Here's the thing about JWTs — they're not encrypted by default. They're just base64-encoded. Decoding the header and payload reveals the claims (user ID, roles, expiry, etc.) but not the signature secret. So pasting the payload into a decoder doesn't inherently expose anything a motivated attacker couldn't already get from intercepting the token in transit.

But there are two real concerns worth thinking about:

Access tokens with sensitive claims — Some JWTs contain internal user IDs, email addresses, org IDs, or permission scopes. Pasting those into a third-party site means you've sent that data to someone else's server.
Trust surface — Even if jwt.io says it decodes client-side, do you know that for sure? Do you trust every CDN it loads from? Do you trust your browser extensions not to capture the input?

Most of the time, for a random dev token in a local dev environment: you're fine. But if you're debugging a production token with real user data? It's worth being a little more intentional.

Option 1: Decode it with `atob()` yourself

You don't need a tool at all. Open DevTools, paste this:

const token = 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c';

const [header, payload] = token.split('.').slice(0, 2).map(
  part => JSON.parse(atob(part.replace(/-/g, '+').replace(/_/g, '/')))
);

console.log('Header:', header);
console.log('Payload:', payload);

Done. No network request. No third-party site. Zero trust required.

This is genuinely the cleanest option for one-off decoding when you're already in the browser or Node.

Option 2: Use a client-side decoder tool

Sometimes you want a nicer UI — syntax highlighting, expiry countdown, a clean view of all claims. For that, AnyTools.io has a JWT decoder that:

Runs entirely in your browser (no token sent to any server)
Requires no login, no account, no cookies
Shows header, payload, and expiry at a glance

I use it when I want something human-readable during a debugging session. It's part of a broader toolkit (JSON formatter, cron builder, color palette, etc.) that I keep bookmarked for the kind of small-but-annoying tasks that eat five minutes if you don't have the right tool.

(Full disclosure: I work as a marketing advocate for AnyTools.io. But I also actually use it, which is why I took the job.)

When to be more careful

If you're dealing with long-lived tokens, internal admin JWTs, or tokens that contain sensitive PII — consider decoding them on an air-gapped machine or in a private VM. The browser DevTools approach (atob()) is safest for those cases.

For everything else in a normal dev workflow, be intentional, not paranoid.

Quick reference

Scenario	Best approach
Quick debugging, dev environment	`atob()` in DevTools
Want a nice UI, no sensitive data	Client-side decoder tool (e.g. anytools.io)
Production tokens with real PII	DevTools only, or dedicated local tool
Batch decoding / automation	Write a small script (`jwt.decode()` in Node)

TL;DR

JWT decoders don't need your secret key to read the payload — that part is just base64. The real risk is sending sensitive claim data to a third party's server. Mitigate that by using atob() in DevTools or a client-side-only tool. Don't panic, just be intentional.

If you've got a smarter approach or a tool I'm missing, drop it in the comments.