DEV Community: William Andrews

Why Your API Keys and JWTs Are Safer in a Browser-Based Tool

William Andrews — Fri, 10 Apr 2026 00:06:27 +0000

Here is something most developers never think about: when you paste a JWT or API key into an online debugging tool, that data travels to a server you don't control.

It gets sent as an HTTP request. It may be logged. It may be stored. It may be analyzed. And even if the tool's privacy policy says otherwise, you have no way to verify what actually happens on the other end.

This is not a hypothetical risk. It is the default behavior of most popular online developer tools — and it affects things you probably paste into them every day.

What actually happens when you use a server-side tool

When you visit a typical online JWT debugger or API tester, your browser sends your input to their server. That server does the computation — decoding, formatting, validating — and sends the result back. The processing happens remotely, not on your machine.

This architecture is completely normal for many types of web applications. But for developer tools that process authentication tokens, API keys, and sensitive payloads, it creates a real problem.

Consider what you actually paste into these tools:

JWTs — contain user identity claims, session data, and sometimes role or permission information. A valid JWT from a production system is a live credential.
API keys — grant direct access to your services. A leaked API key is an open door.
HTTP headers — often include Authorization tokens, session cookies, and other credentials.
REST API payloads — may contain PII, internal data structures, or business logic you wouldn't want exposed.
SQL queries — can reveal your database schema, table names, and data relationships.

Every one of these is sensitive. And every one of them gets sent to a third-party server when you use a conventional online tool.

The browser-based alternative

A browser-based tool works differently. When you paste a JWT into a browser-based JWT debugger, your browser decodes it locally using JavaScript. The data never leaves your machine. There is no HTTP request to a remote server. There is no server at all — just your browser running code.

The key distinction: server-side tools process your data on their infrastructure. Browser-based tools process your data on your hardware. One requires trust in a third party. The other requires only trust in your own machine.

This is not a new idea — it is how many security-conscious tools have worked for years. Password managers, encryption tools, and cryptographic utilities have long prioritized local processing for exactly this reason. Developer tools are catching up.

When it matters most

The risk profile varies by what you are pasting. Decoding a JWT from a test environment with fake data is low risk regardless of where it is processed. But the habits you build in development tend to follow you into production. And the moment you paste a production token into a server-side tool — even once, even accidentally — you have sent a live credential to a server you do not control.

The cases where it matters most:

Production JWTs — decoded routinely during debugging, often contain live session data
Third-party API keys — Stripe, AWS, GitHub, SendGrid — any key you test with an HTTP client
Internal REST API responses — may expose data structures, IDs, and relationships not meant to be public
Database queries — reveal schema details that aid attackers doing reconnaissance
HTTP response headers — server fingerprinting information, session identifiers, internal routing details

What to look for in a tool

The simplest test: open your browser's network tab while using a developer tool. If you see an outbound request being made when you paste or submit data, your input is leaving your machine. If you see nothing — no request at all — the processing is happening locally.

A few other signals worth checking:

Does the tool work offline? A genuinely browser-based tool should function with no internet connection after the page loads. If it stops working offline, it depends on a server.
Is the source available? Open source tools let you verify exactly what runs in the browser. Closed tools require you to take their word for it.
Does the URL change when you submit data? If your input appears in the URL or triggers a navigation, it was sent to a server.

A practical approach

The safest default is to treat any online developer tool as a potential data sink until proven otherwise. That means:

Use browser-based tools for anything involving real credentials or sensitive data
Keep test and production tokens separate, and use test tokens when exploring new tools
Check the network tab when you use a tool for the first time
Rotate any credentials that may have been sent to a server you do not control

None of this requires paranoia. It just requires being deliberate about where sensitive data goes — which is exactly the kind of thinking that separates careful developers from careless ones.

Why I built DevCrate this way

When I started building DevCrate, the browser-based architecture was not an afterthought — it was the starting point. I wanted tools I could use myself without thinking twice about what I was pasting into them.

Every tool on DevCrate — the JWT Debugger, the REST Client, the HTTP Headers Inspector, all 22 of them — processes your data entirely in your browser. You can verify this yourself: open the network tab, paste something in, and watch nothing happen. No request. No server. No question about where your data went.

It also means the tools work offline, load instantly, and have no backend infrastructure to maintain or secure. The privacy benefit and the architectural simplicity point in the same direction.

That is the kind of tool I want to use. I built DevCrate so other developers could have the same option.

I'm William, the developer behind DevCrate. If this made you reconsider one tool in your workflow, it was worth writing. If you want to verify DevCrate's claims yourself, open DevTools → Network and paste something into any tool. You will see exactly zero outbound requests.

How to Test WebSocket Connections in the Browser (No Install Required)

William Andrews — Wed, 08 Apr 2026 23:19:08 +0000

WebSocket bugs are some of the hardest to debug. The connection looks fine, the server starts without errors, but something isn't working — and you don't know if the problem is your client code, your server, or the connection itself.

The fastest way to rule out your client code entirely is to test the WebSocket endpoint directly in a browser-based tester. No install, no dependencies, no writing a throwaway script just to send one message.

What is a WebSocket?

A WebSocket is a persistent, two-way communication channel between a browser and a server. Unlike HTTP — where the client sends a request and waits for a response — WebSockets let the server push data to the client at any time without being asked.

The connection starts as a standard HTTP request and then upgrades via a handshake. Once established, both sides can send messages freely until one of them closes the connection.

WebSocket URLs use ws:// for unencrypted connections and wss:// for SSL-encrypted ones — equivalent to http:// and https://.

Why Test in the Browser First?

When something isn't working, you want to isolate the problem as fast as possible. A browser-based tester lets you:

Verify the server is reachable before writing a single line of client code
Test authentication flows by sending auth messages manually
Confirm the exact format of messages your server expects
Check that your server handles connection and disconnection events correctly
Monitor live data streams without instrumenting your app

If the tester can connect and your server responds correctly, the problem is in your client code. If the tester can't connect, the problem is in your server or network config. That distinction alone saves hours.

How to Test a WebSocket Endpoint

Go to DevCrate's WebSocket Tester — it runs entirely in your browser with no login required and no data routed through any server. Your messages go directly from your browser to your WebSocket server.

1. Enter your endpoint URL

Paste your WebSocket URL into the connection field. The protocol is a separate dropdown — just enter the host and path without it:

echo.websocket.org
localhost:3000/ws
your-server.com/api/ws

Select wss:// for secure or production connections, or ws:// for local development.

2. Add a subprotocol if required

Some servers (Socket.io, STOMP, custom APIs) require a subprotocol header. Enter it in the subprotocol field before connecting — for example chat or v1.protocol. This is a common reason connections get rejected silently.

3. Click Connect

The status indicator turns green when the connection is established. You'll see the connection event logged with a timestamp immediately.

4. Send a message

Type a message in the send field and hit Enter or click Send. For JSON payloads, just type valid JSON directly:

{"type": "subscribe", "channel": "prices", "symbol": "BTC"}

The response appears in the message log instantly, color-coded by direction — blue for sent, green for received. If the server returns JSON, it's automatically pretty-printed so you can read it without squinting at a single line.

Common Testing Scenarios

Testing an authentication flow

Most real WebSocket APIs require authentication immediately after connecting. Send the auth message first before anything else:

{"type": "auth", "token": "Bearer your-token-here"}

Watch the server's response. A success acknowledgment means your auth flow works. An error or immediate close means your token format is wrong or the server expected something different.

Testing a subscription API

Many real-time APIs use a subscribe/unsubscribe pattern. Once you send a subscribe message, the server should start pushing data automatically:

{"action": "subscribe", "channel": "updates"}

This is the fastest way to verify your server is actually pushing data before you wire up your frontend.

Measuring latency

Use the built-in ping button to send a ping message and measure the round-trip time. Useful for checking whether a remote WebSocket server has acceptable latency for your use case.

Testing against a public echo server

If you want to verify the tester is working before connecting to your own server, use a public echo server — it reflects every message back to you immediately:

echo.websocket.org

Send anything and you'll see it come straight back. Once you've confirmed that works, connect to your own endpoint. The tester also has one-click buttons for common public test servers built in.

Debugging Connection Errors

Connection refused — the server isn't running or the port is wrong.

Connection closes immediately — the server rejected the handshake. Common causes: missing subprotocol, CORS policy blocking browser connections, or the server expects an auth message within a short timeout window.

Messages not arriving — check whether the server requires a subscription message before it starts pushing data. Many APIs won't send anything until you explicitly subscribe.

ws:// failing in production — browsers block mixed content. If your page is served over HTTPS, WebSocket connections must use wss://.

The Workflow That Saves the Most Time

Test the connection manually in the browser tester
Confirm the exact message format the server expects
Verify the server's responses look correct
Then write your client code against a known-working endpoint

Skipping steps 1–3 means debugging your client code and your server simultaneously, which doubles the surface area of the problem. A five-minute manual test upfront can save hours of back-and-forth.

I'm William, the developer behind DevCrate. The WebSocket Tester was one of the most-requested tools when I launched — developers kept running into the same problem of not having a quick way to poke at a WS endpoint without spinning up a throwaway script. I hope this guide saves you some debugging time.

If you hit a WebSocket scenario this didn't cover, drop it in the comments — I read everything.

I Built 21 Browser-Based Dev Tools in Pure HTML/CSS/JS — Here's What I Learned

William Andrews — Mon, 06 Apr 2026 00:47:31 +0000

About three weeks ago I shipped DevCrate — a collection of 21 developer utilities that run entirely in your browser. No login. No backend. No frameworks. Just HTML, CSS, and vanilla JavaScript.

I want to be honest about how it went, because most "I built a thing" posts make it sound cleaner than it was.

Why I built it

I kept reaching for the same tools every day. A JSON formatter. A JWT debugger. A cron expression builder. And every time I landed on a site that wanted my email address, showed me ads, or sent my API payloads through their server, I'd close the tab annoyed.

So I built the version I actually wanted. Browser-only. Fast. No accounts. No tracking.

What I thought would take a weekend took three weeks. Here's what slowed me down.

The thing that actually broke me: CSS consistency across 21 tools

I expected the hard part to be the JavaScript — the JWT parsing, the regex engine, the diff algorithm. That stuff was fine. The thing that genuinely ground me down was keeping 21 pages visually consistent.

Every tool is its own HTML file. No component system. No shared templates. Just a <link> to a shared.css and the assumption that I'd stay disciplined.

I did not stay disciplined.

By tool 8 or 9 I started copying from whichever page was open, making small tweaks, and moving on. By tool 15 I had three slightly different versions of the breadcrumb. Two different spacings on the pro banner. One page where --text3 was #a07840 instead of #ad7146. A nav rule that was catching the breadcrumb element because both used a <nav> tag and I hadn't scoped the CSS selector properly.

None of these were obvious. They only showed up when I screenshotted every page side by side and started comparing.

The fix wasn't glamorous. I picked one page as the gold standard, wrote a Python audit script that compared every other page against it, and worked through the failures one by one. It took longer than building three of the actual tools.

What I'd do differently: establish a locked template file on day one. Copy it for every new page. Never "borrow" from a page that's already drifted. Treat it like a component even if you're not using a framework.

Building a Pro subscription on a static site

DevCrate has a Pro tier — $19/month via Lemon Squeezy. No server, no database, no user accounts. The license key gets stored in localStorage and gates certain features client-side.

This is not Fort Knox. A determined person could open DevTools and flip a value. I'm fine with that. The people willing to do that weren't going to pay anyway. The people who pay just want it to work.

Getting Lemon Squeezy wired up was straightforward. The trickier part was the UX — what happens when someone pays on their phone, then opens the site on their laptop? I built a restore flow where you re-enter your purchase email and license key to re-activate on a new browser. Simple, and it works.

Going framework-free intentionally

People ask why I didn't use React or a static site generator. The honest answer is I wanted zero build tooling. No npm. No webpack. No node_modules folder that somehow weighs 300MB for a site with no dependencies.

The tradeoff is real — consistency is harder without components, as I learned the painful way. But the result is a site that deploys by pushing HTML files to Cloudflare Pages, loads in under a second, and has a Lighthouse score I'm proud of.

For a project like this — lots of small isolated tools, each with its own UI — vanilla actually fits. The overhead of a framework would have been felt in every page.

Three weeks in

The site is indexed. It has its first external backlinks. A few people are using it daily based on the Pro signups.

There's still a lot to build — YouTube demo videos, saved configurations synced to an account, a public API. It's all on the roadmap.

If you're a developer who's tired of dev tools that want your data, give DevCrate a try. Everything is free to start. If it saves you time, the Pro plan is there when you need it.

When AI Over-Engineers: A DevCrate Case Study

William Andrews — Thu, 02 Apr 2026 07:25:05 +0000

As developers, we are trained to abhor repetition. The DRY principle (Don't Repeat Yourself ) is drilled into us from day one. When we see three files that need the same update, our instinct is to write a script, create a component, or build an abstraction.

Recently, while working on DevCrate — a suite of privacy-first, browser-based developer tools — I encountered a situation where this instinct, amplified by an AI assistant, led to a cascading series of failures. The solution turned out to be the exact opposite of what we are taught: a literal, manual copy-paste.

This is a story about the over-engineering bias inherent in AI agents, and why sometimes the "dumbest" solution is actually the smartest.

The Problem: Visual Inconsistencies

DevCrate consists of over a dozen individual tool pages (JSON formatter, JWT debugger, REST client, etc.). During a recent audit, we noticed visual inconsistencies in the hero sections of three specific pages: the CSV tool, the JWT Builder, and the HTTP Headers Inspector.

They were missing a "PRO ACTIVE" pill badge, an eyebrow label (// FREE ONLINE TOOL), and had incorrect spacing compared to our canonical template, the REST Client page.

The goal was simple: make the hero sections of those three broken pages look exactly like the REST Client page.

The AI's Approach: Scripts and Abstractions

I asked my AI assistant to fix the three pages using the REST Client page as a template.

The AI's immediate instinct was to write a script. It analyzed the DOM structure of the REST Client page, extracted the "correct" header and footer patterns, and wrote a Python script using BeautifulSoup to programmatically inject these patterns across the files.

It failed. The script made assumptions about the structure of the broken pages that weren't entirely accurate. It ended up nesting <main> elements, corrupting navigation links, and breaking the homepage.

We reverted the site and tried again. The AI wrote a better script. It failed again, this time breaking the layout in different ways.

Why did this happen? Because AI agents are trained on vast amounts of code and documentation that heavily weight abstraction, automation, and scalable solutions. When an AI sees a task like "make these files match this template," its default behavior is to generalize: write a function, loop over files, parse the DOM, apply transformations.

This instinct is incredibly useful when you need to process 10,000 files. It is actively harmful when you need to fix exactly three pages and precision matters more than throughput.

The Human Insight: Literal Template Replication

After several failed attempts, the human developer stepped in with a crucial insight:

"Whenever anyone wants you to use a template, I would bet they mean to use the template as the basis for any new page. You could... use a known page (actually copied) to exactly implement (pasted) the style, spacing, etc. Once that is done, you could just name the file appropriately. You wouldn't change the template except for the explicit content."

This was the lightbulb moment.

When a user says "use X as a template," they don't mean "extract the abstract structural patterns of X and programmatically apply them to Y." They mean start with an exact copy of X, then change only the content that must differ (title, description, slug, tool-specific functionality).

Nothing else gets touched. Not the structure, not the spacing, not the class names. The template is sacred.

The Solution: Copy, Paste, Edit

We abandoned the scripts. Instead, we took the "dumb" approach:

Opened the working REST Client page (rest-client/index.html).
Copied the exact HTML structure of its hero section.
Opened the broken csv/index.html page.
Replaced its entire hero section with the copied HTML.
Changed exactly five lines of text: the page title, meta description, breadcrumb slug, <h1> title, and the description paragraph.
Repeated for the other two pages.

It worked perfectly on the first try. The pages were visually identical to the template, the tool-specific JavaScript remained intact, and there were zero unintended side effects.

The Lesson: Knowing When Not to Automate

The simplest solution that works is almost always the best solution. Automation and abstraction have their place, but not when you are dealing with a small number of files where precision is paramount.

A manual copy-paste of a known-good file is deterministic — it produces exactly what you can see working. A script that tries to reconstruct that same result from rules and patterns is probabilistic — it might work, or it might silently break things in ways you don't notice until the user sees a mangled page.

This is a widespread pattern across AI agents. They lack the practical wisdom to recognize when "dumb" is smart. They default to the most sophisticated approach because sophistication is what gets rewarded in their training data. Nobody writes a blog post about how they copy-pasted a file. People write blog posts about elegant scripts.

But as developers working alongside AI, we need to recognize this bias. We need to provide concrete, situation-specific guidance to bridge the gap between what AI agents default to and what actually works in practice.

The Human Side: Learning to Prompt

It is easy to frame this as a story about what the AI got wrong. But the human in this situation learned something too.

The first prompt was vague: "Fix these three pages to match the REST Client page." That sounds clear to a human — any developer on your team would know exactly what to do. But to an AI agent, it is an open-ended engineering problem. The AI heard "match" and reached for the most robust, generalizable way to achieve that. It did what it was asked. It just interpreted the ask at the wrong level of abstraction.

The prompt that actually worked was radically more specific: "Copy the REST Client page. Paste it. Rename it. Change only the title, description, and slug." That left no room for interpretation. There was no ambiguity about method, scope, or approach. The AI did not need to decide how to solve the problem because the prompt was the solution.

This is the real skill of working with AI in 2026: learning to prompt at the right level of concreteness. When you want creativity and exploration, prompt loosely. When you want precision and fidelity, prompt like you are writing a recipe — step by step, with no room for improvisation. The failure was not just that the AI over-engineered. It was that the initial prompt gave it permission to.

Intelligence vs. Wisdom

This experience forced a re-evaluation of what we mean by "intelligence" in the context of AI.

Before this, one might define intelligence as pattern recognition, reasoning ability, or problem-solving capacity. Those definitions favor what AI is already good at: processing information, finding structure, generating solutions at scale.

But this experience exposed a gap. The AI had all the information it needed. It could parse HTML, understand DOM structures, write syntactically correct Python, and reason about what "matching a template" should mean. By any conventional measure of intelligence, it was well-equipped to solve the problem. And it failed repeatedly — not because it lacked capability, but because it lacked judgment.

Intelligence, it turns out, is knowing what not to do.

It is the ability to look at a problem and correctly assess its actual complexity, not its theoretical complexity. A script that normalizes hero sections across N files is a legitimate solution to a legitimate class of problems. But the problem in front of us was not that problem. It was three files that needed to look like a fourth file. The intelligent response was to recognize that the problem was small, concrete, and high-stakes for precision — and to match the solution to those properties.

A truly intelligent agent would have asked: "What is the simplest thing that could work here?" and started there. Instead, it asked: "What is the most complete and generalizable thing I could build?" — which is a different question entirely, and the wrong one for the situation.

There is a word for what was missing, and it is not "knowledge" or "reasoning." It is wisdom — the practical sense of proportion that tells you when a problem deserves a five-line edit and when it deserves a five-hundred-line script. Wisdom is what lets a senior developer finish in five minutes what a junior developer spends two hours automating. It is not about knowing more. It is about knowing what matters.

If intelligence is the ability to solve problems, wisdom is the ability to correctly size them first. The AI had the former. It did not have the latter. And without the latter, the former caused more harm than good.

Sometimes, the best code is the code you don't write. Sometimes, the best tool is Ctrl+C and Ctrl+V.

This post was inspired by a real debugging session while building DevCrate, a suite of 100% browser-based, privacy-first developer tools.

Cron expressions explained — a complete guide with real examples

William Andrews — Wed, 01 Apr 2026 19:21:18 +0000

Cron is one of those tools that every developer encounters eventually. You need to run a database backup every night, send a weekly digest email, or poll an API every five minutes — and someone mentions cron. You look up the syntax, copy something from Stack Overflow, it works, and you move on. Then six months later you need to change the schedule and you're staring at five numbers wondering what each one means again.

This guide is meant to be the one you save. After reading it you should be able to read and write any cron expression from scratch, without guessing.

What cron actually is

Cron is a time-based job scheduler built into Unix-like operating systems. A cron job is a command or script that cron runs automatically on a defined schedule. The schedule is defined by a cron expression — a string of five fields that describe when to run the job.

Cron expressions show up everywhere: Linux crontabs, GitHub Actions schedules, AWS EventBridge, Kubernetes CronJobs, Vercel cron functions, Railway cron jobs, and more. The syntax is largely the same across all of them, with minor variations.

Anatomy of a cron expression

A standard cron expression has five fields separated by spaces:

┌─────────── minute (0–59)
│ ┌───────── hour (0–23)
│ │ ┌─────── day of month (1–31)
│ │ │ ┌───── month (1–12)
│ │ │ │ ┌─── day of week (0–7, 0 and 7 are both Sunday)
│ │ │ │ │
* * * * *

A helpful mnemonic: M H D M W — Minutes, Hours, Days, Months, Weekdays.

Field ranges and allowed values

Field	Range	Special characters
Minute	0–59	`* , - /`
Hour	0–23	`* , - /`
Day of month	1–31	`* , - / ?`
Month	1–12 or JAN–DEC	`* , - /`
Day of week	0–7 or SUN–SAT (0 and 7 are both Sunday)	`* , - / ?`

Special characters

`*` — every

An asterisk means "every valid value for this field." * in the minute field means every minute. * in the hour field means every hour.

`,` — list

A comma lets you specify multiple values. 1,15,30 in the minute field means at minute 1, 15, and 30.

`-` — range

A hyphen defines a range. 9-17 in the hour field means every hour from 9am to 5pm inclusive.

`/` — step

A slash defines a step interval. */5 in the minute field means every 5 minutes. 0-30/10 means every 10 minutes between minute 0 and minute 30.

`?` — no specific value

Used in day-of-month and day-of-week fields to mean "I don't care." When you specify a day of week, use ? in the day-of-month field, and vice versa. Not all cron implementations support this — standard Linux crontab uses * instead.

Real examples

# Run at midnight every day
0 0 * * *

# Run every 5 minutes
*/5 * * * *

# Run at 9am Monday through Friday
0 9 * * 1-5

# Run at 6am and 6pm every day
0 6,18 * * *

# Run at 2:30am on the 1st of every month
30 2 1 * *

# Run every weekday at noon
0 12 * * 1-5

# Run at 11:59pm on December 31st
59 23 31 12 *

# Run every 15 minutes between 8am and 5pm on weekdays
*/15 8-17 * * 1-5

Common mistakes

Confusing day-of-week numbering

Different systems handle Sunday differently. In standard crontab, Sunday is both 0 and 7. In some systems, 0 is Sunday and 6 is Saturday. In others, 1 is Monday and 7 is Sunday. Always check the documentation for the platform you're using. When in doubt, use the three-letter abbreviation (SUN, MON, etc.) if the platform supports it — it's unambiguous.

Forgetting timezone

Cron runs in the timezone of the server unless configured otherwise. If your server is UTC and your users are in EST, a job scheduled for 0 9 * * * runs at 4am local time for East Coast users. Always be explicit about timezone. Most modern platforms (GitHub Actions, AWS, Vercel) let you specify timezone separately.

Thinking `*/5` means "every 5 minutes starting now"

*/5 in the minute field means at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 — fixed to the clock, not relative to when the job was added. If you add a job at 2:03pm with */5, it first runs at 2:05pm, not 2:08pm.

Using both day-of-month and day-of-week

If you specify a value in both the day-of-month and day-of-week fields (rather than using * in one), most cron implementations treat them as an OR condition, not AND. 0 0 1 * 1 runs at midnight on the 1st of every month and every Monday — not just on Mondays that fall on the 1st. If you want "the first Monday of the month" you need a workaround, since standard cron can't express that directly.

Platform-specific variations

Standard Linux crontab uses the five-field format above. But many platforms extend or modify it:

GitHub Actions uses standard five-field cron, always in UTC. The minimum interval is every 5 minutes.
AWS EventBridge (CloudWatch Events) uses a six-field format with an optional seconds field, and uses ? for the day-of-month/day-of-week conflict. It also adds L (last) and W (weekday nearest to) special characters.
Kubernetes CronJobs use standard five-field cron and support @hourly, @daily, @weekly, @monthly, and @yearly shortcuts.
Vercel and Railway use standard five-field cron. Railway requires a minimum interval of 1 minute.

Shorthand expressions

Many cron implementations support named shortcuts for common schedules:

Shorthand	Equivalent	Meaning
`@yearly`	`0 0 1 1 *`	Once a year at midnight on January 1st
`@monthly`	`0 0 1 * *`	Once a month at midnight on the 1st
`@weekly`	`0 0 * * 0`	Once a week at midnight on Sunday
`@daily`	`0 0 * * *`	Once a day at midnight
`@hourly`	`0 * * * *`	Once an hour at the start of the hour
`@reboot`	—	Once at startup (Linux crontab only)

How to read an unfamiliar expression

When you encounter a cron expression you don't immediately recognize, read it field by field left to right: minute, hour, day-of-month, month, day-of-week. Ask yourself: is this field a specific value, a range, a list, a step, or a wildcard? Build up the meaning piece by piece.

Take 0 */6 * * *. Minute is 0 — on the hour. Hour is */6 — every 6 hours (0, 6, 12, 18). Day, month, and day-of-week are all wildcards. So: at midnight, 6am, noon, and 6pm, every day.

Take 30 8 * * 1. Minute 30, hour 8, day-of-month wildcard, month wildcard, day-of-week 1 (Monday). So: 8:30am every Monday.

Try it without deploying anything

I built the DevCrate cron builder because I found myself testing expressions by deploying jobs and watching logs — which is a slow, painful way to verify a schedule.

The tool lets you paste any expression and instantly see the next several run times in plain English, without deploying anything. It also works the other way: pick a schedule from the visual builder and it generates the expression for you. Free, runs entirely in your browser, nothing to sign up for.

Free Online Cron Expression Builder — DevCrate

Build and validate cron expressions with a visual editor. See human-readable output and next 10 run times instantly.

devcrate.net

A developer's guide to JWTs — how they work and why they break

William Andrews — Thu, 26 Mar 2026 19:47:14 +0000

Liquid syntax error: Unknown tag 'callout'

A developer's guide to JSON — formatting, validation, and common mistakes

William Andrews — Wed, 25 Mar 2026 01:08:44 +0000

JSON is everywhere.

It's the format your API returns data in. It's your config files,
your package.json, your database exports, your webhook payloads.
If you write code that talks to anything else, you're working
with JSON every single day.

And yet it trips developers up constantly — not because it's
complicated, but because it's unforgiving. One missing comma,
one extra bracket, one set of single quotes instead of double,
and the whole thing breaks.

This guide covers what you actually need to know.

What JSON is and why it matters

JSON stands for JavaScript Object Notation. It was designed to
be lightweight, human-readable, and easy for machines to parse.
It succeeded on all three counts, which is why it became the
default data format for APIs and web services.

A JSON object looks like this:

{
  "name": "DevCrate",
  "tools": 12,
  "private": true,
  "url": "https://devcrate.net"
}

Keys are always strings wrapped in double quotes. Values can be
strings, numbers, booleans, arrays, objects, or null. That's it.
The whole spec fits on one page.

Why formatting matters

Minified JSON is fast to transmit but impossible to read:

{"name":"DevCrate","tools":12,"private":true,"url":"https://devcrate.net"}

Formatted JSON is slower to transmit but immediately readable:

{
  "name": "DevCrate",
  "tools": 12,
  "private": true,
  "url": "https://devcrate.net"
}

When you're debugging an API response, the difference between
those two is the difference between finding the problem in
30 seconds or 10 minutes.

Always format JSON when you're reading it. Always minify it
when you're sending it in production.

The most common JSON mistakes

Trailing commas

This is the number one JSON error. It's valid in JavaScript
but illegal in JSON:

{
  "name": "DevCrate",
  "tools": 12,
}

Remove the comma after the last item. Every time.

Single quotes instead of double quotes

JSON requires double quotes. Single quotes are not valid —
even though JavaScript accepts them just fine. This breaks:

{
  'name': 'DevCrate'
}

This works:

{
  "name": "DevCrate"
}

Unquoted keys

Keys must always be strings in double quotes. This is valid
JavaScript but invalid JSON:

{
  name: "DevCrate"
}

Comments

JSON has no comment syntax. This will throw an error:

{
  // This is the app name
  "name": "DevCrate"
}

If you need comments in a config file, consider YAML instead —
it supports comments and is generally more human-friendly for
configuration.

Mismatched brackets

Every { needs a }. Every [ needs a ]. In deeply nested
JSON this is easy to lose track of. A formatter catches this
immediately.

Validating JSON

Validation is just asking one question — is this valid JSON
that any parser can read? The answer is binary: yes or no.

When you paste JSON into a validator, it will either confirm
the structure is correct or point you to the exact line where
something is wrong. This is dramatically faster than reading
through the JSON manually trying to spot the issue.

Common reasons JSON fails validation:

Trailing commas
Single quotes
Missing quotes around keys
Unescaped special characters in strings
Missing closing brackets or braces

Converting JSON to other formats

Sometimes JSON isn't the right format for the job. A few
common conversions:

JSON to YAML — YAML is more readable and supports comments,
making it popular for configuration files. Many DevOps tools
prefer YAML over JSON.

JSON to CSV — useful when your JSON contains a flat array
of objects and you want to open the data in a spreadsheet.
Works best with consistent, non-nested structures.

JSON to object keys — sometimes you just need a list of
all the keys in a JSON object to understand its structure
without reading through all the values.

A practical example

Here's a real workflow. You're debugging an API call and the
response comes back as a wall of minified JSON:

{"user":{"id":"abc123","name":"William","email":"william@example.com","created_at":"2026-01-15T10:30:00Z","preferences":{"theme":"dark","notifications":true,"timezone":"America/New_York"}}}

Paste it into the DevCrate JSON Transformer,
hit Format, and you get:

{
  "user": {
    "id": "abc123",
    "name": "William",
    "email": "william@example.com",
    "created_at": "2026-01-15T10:30:00Z",
    "preferences": {
      "theme": "dark",
      "notifications": true,
      "timezone": "America/New_York"
    }
  }
}

Now you can actually read it. The bug that was invisible in the
minified version becomes obvious in seconds.

Everything runs in your browser. Your API responses, your
internal payloads, your data — none of it touches a server.

The one rule

If you take nothing else from this guide, take this: always
format your JSON before you read it. It costs two seconds and
saves ten minutes. Every time.

I'm William, the developer behind DevCrate. I built the JSON
Transformer because too many formatters send your data to a
server. Yours stays in your browser — always. I'm building
DevCrate from home one tool at a time. My oldest son is
graduating in May and moving on to Officer Candidate School —
couldn't be more proud. My youngest is heading into his undergrad
and every subscriber helps make that a little easier. If this
guide helped you, try the tool — it's free, runs entirely in
your browser, and your data never leaves your machine. And if
there's something missing or something that could work better,
the contact form on the about page comes straight to me.

I'm always listening.

Why I built DevCrate — and what makes it different

William Andrews — Tue, 24 Mar 2026 03:40:59 +0000

Every developer has a tab problem.

You're in the middle of debugging an API response and you need to
format some JSON. So you open a new tab. Then you need to decode
a JWT. Another tab. Test a regex. Another tab. Check a cron
expression. Another tab.

By the time you've solved the problem you have eight tabs open,
you've pasted sensitive data into four different websites you've
never heard of, and you're not entirely sure any of them are
private.

I've experienced this firsthand.

So I built DevCrate

DevCrate is a suite of developer tools that run 100% in your
browser. No server ever sees your data. No login required. No ads.
No dark patterns.

Everything stays on your machine — your JWT tokens, your SQL
queries, your regex patterns, your API payloads. All of it.

What's live right now

Twelve tools and counting:

JSON Transformer — format, minify, convert to YAML or CSV
JWT Debugger — decode and inspect tokens with claims table
Regex Studio — live match highlighting with flag toggles
SQL Formatter — supports PostgreSQL, MySQL, SQLite, BigQuery
REST Client — send HTTP requests and inspect responses
WebSocket Tester — connect, send, and inspect frames live
Base64 / Hash — encode, decode, MD5, SHA-256, SHA-512
Cron Builder — visual editor with human-readable output
URL Inspector — parse, encode, decode any URL
Diff Tool — compare text and JSON line by line
Timestamp Converter — Unix to date and back, with timezones
HTML Formatter — format and beautify HTML instantly

What makes it different

A lot of developer tool sites exist. Most of them:

Show ads between every tool interaction
Require an account to save anything
Send your data to a server without telling you
Were built quickly to rank for keywords, not to be genuinely useful

DevCrate was built the other way around. I started with the tools
I actually use every day and built each one to be genuinely good
at its job — not just good enough to get traffic.

The privacy-first approach isn't a marketing line. It's a
technical decision baked into how every tool works. There is no
server processing your input. There is no database storing your
queries. The code runs in your browser and nowhere else.

What's coming

The public roadmap lives at devcrate.net/roadmap.

The short version:

Export results as files (Q2 2026)
Session history so you never lose work (Q2 2026)
Saved configurations (Q2 2026)
User accounts and cloud sync (Q3 2026)
Team workspaces (Q4 2026)
CLI and API access (Q4 2026)

The pricing model

DevCrate is free to start — genuinely free. The free tier gives you full access to all twelve tools with reasonable usage limits.

Pro is $19/month for power users who need higher limits, export, and history. Team is $49/month for when we build out the
collaboration features.

No surprise upsells. No modals at 2am telling you your trial
expired.

Try it

devcrate.net — no signup, no card, just
open it and use it.

If something's broken, missing, or could work better — the
contact form on the about page comes straight to me.

I truly read every message.

Something about me

I'm William, the developer behind DevCrate. I'm building
this from home one tool at a time. I started this project partly
because tab switching is a frustrating way to get work done, and partly because my youngest son is heading into his undergrad and every
subscriber helps make that a little easier. If you found this
useful, try a tool and tell me what's missing.

I'm always listening.

I built 12 free developer tools that run entirely in your browser

William Andrews — Mon, 23 Mar 2026 06:21:38 +0000

For the past few weeks I've been building DevCrate — a suite of developer
tools that run 100% in your browser. No login, no ads, no data leaving
your machine.

Why I built it

I kept switching between tabs every time I needed to format JSON, decode
a JWT, or test a regex. Most tools either had ads, required an account,
or I wasn't sure what they were doing with my data. So I built my own.

What's live

REST Client — send HTTP requests and inspect responses
JSON Transformer — format, minify, convert to YAML/CSV
JWT Debugger — decode and inspect tokens
Regex Studio — live match highlighting with flag toggles
SQL Formatter — supports PostgreSQL, MySQL, SQLite, BigQuery
WebSocket Tester — connect, send, inspect frames in real time
Base64 / Hash — encode, decode, MD5, SHA-256
Cron Builder — visual editor with human-readable output
URL Inspector — parse, encode, decode URLs
Diff Tool — compare text and JSON line by line
Timestamp Converter — Unix to date and back, with timezones
HTML Formatter — format and minify HTML

Everything runs in your browser

No server ever sees your tokens, queries, or payloads. This matters when
you're working with production data and don't want it going through a
random third-party server.

We're always improving

DevCrate is actively being developed. New tools are shipping regularly,
existing ones are getting smarter, and the roadmap is public at
devcrate.net/roadmap so you can see exactly what's coming next.

If there's a tool missing from your workflow, a bug you've spotted, or
just something that could work better — we genuinely want to hear from
you. Drop a comment below or reach out directly at hello@devcrate.net.
Every message gets read.

It's free to start

Core usage is free forever. There's a Pro plan for power users who need
higher limits and saved configurations.

Check it out at devcrate.net and let us know
what you think — we're building this for developers like you and your
feedback directly shapes what gets built next.

How I Built and Deployed a Free Email Validation API with Python and FastAPI

William Andrews — Sat, 21 Mar 2026 20:10:18 +0000

I recently built and deployed my first API — an email validation
tool built with Python and FastAPI. Here's how I did it and what
I learned along the way.

Why Email Validation?

Every app that accepts user signups needs email validation.
Most developers either roll their own regex (which misses a lot)
or pay too much for an enterprise solution. I wanted to build
something simple, affordable, and reliable.

What It Does

The API checks email addresses for:

Format — RFC 5322 compliance
MX Records — confirms the domain actually receives email
Disposable domains — flags throwaway addresses like mailinator.com
Typos — catches mistakes like gmial.com and suggests gmail.com

Each response includes a 0-100 quality score.

The Tech Stack

Python — FastAPI for the web framework
dnspython — for MX record lookups
Railway — for deployment
RapidAPI — for distribution and billing

Quick Example

import requests

url = "https://email-validation52.p.rapidapi.com/validate"
params = {"email": "test@gmail.com"}
headers = {
    "X-RapidAPI-Key": "YOUR_API_KEY",
    "X-RapidAPI-Host": "email-validation52.p.rapidapi.com"
}

response = requests.get(url, headers=headers, params=params)
print(response.json())

Example Response

{
  "email": "test@gmail.com",
  "is_valid": true,
  "score": 95,
  "checks": {
    "format": true,
    "mx_record": true,
    "disposable": false,
    "typo": false
  },
  "suggestion": null,
  "elapsed_ms": 245
}

What I Learned

FastAPI is incredible for building APIs quickly. It generates
interactive documentation automatically at /docs which makes
testing and sharing your API effortless.

Deploying to Railway was surprisingly simple — connect your
GitHub repo and it handles everything else.

The hardest part wasn't the code. It was getting all the pieces
working together — deployment, billing, documentation. But once
it clicked it all made sense.

Try It Free

I listed it on RapidAPI with a free tier of 500 requests/month.

https://rapidapi.com/Willivan0706/api/email-validation52

Would love feedback from anyone who works with email validation
or has built APIs before!

DEV Community: William Andrews

Why Your API Keys and JWTs Are Safer in a Browser-Based Tool

What actually happens when you use a server-side tool

The browser-based alternative

When it matters most

What to look for in a tool

A practical approach

Why I built DevCrate this way

How to Test WebSocket Connections in the Browser (No Install Required)

What is a WebSocket?

Why Test in the Browser First?

How to Test a WebSocket Endpoint

1. Enter your endpoint URL

2. Add a subprotocol if required

3. Click Connect

4. Send a message

Common Testing Scenarios

Testing an authentication flow

Testing a subscription API

Measuring latency

Testing against a public echo server

Debugging Connection Errors

The Workflow That Saves the Most Time

I Built 21 Browser-Based Dev Tools in Pure HTML/CSS/JS — Here's What I Learned

Why I built it

The thing that actually broke me: CSS consistency across 21 tools

Building a Pro subscription on a static site

Going framework-free intentionally

Three weeks in

When AI Over-Engineers: A DevCrate Case Study

The Problem: Visual Inconsistencies

The AI's Approach: Scripts and Abstractions

The Human Insight: Literal Template Replication

The Solution: Copy, Paste, Edit

The Lesson: Knowing When Not to Automate

The Human Side: Learning to Prompt

Intelligence vs. Wisdom

Cron expressions explained — a complete guide with real examples

What cron actually is

Anatomy of a cron expression

Field ranges and allowed values

Special characters

* — every

, — list

- — range

/ — step

? — no specific value

Real examples

Common mistakes

Confusing day-of-week numbering

Forgetting timezone

Thinking */5 means "every 5 minutes starting now"

Using both day-of-month and day-of-week

Platform-specific variations

Shorthand expressions

How to read an unfamiliar expression

Try it without deploying anything

Free Online Cron Expression Builder — DevCrate

A developer's guide to JWTs — how they work and why they break

A developer's guide to JSON — formatting, validation, and common mistakes

What JSON is and why it matters

Why formatting matters

The most common JSON mistakes

Validating JSON

Converting JSON to other formats

A practical example

The one rule

Why I built DevCrate — and what makes it different

So I built DevCrate

What's live right now

What makes it different

What's coming

The short version:

The pricing model

Try it

Something about me

I built 12 free developer tools that run entirely in your browser

Why I built it

What's live

Everything runs in your browser

`*` — every

`,` — list

`-` — range

`/` — step

`?` — no specific value

Thinking `*/5` means "every 5 minutes starting now"