DEV Community: William Andrews

How to decode and debug a JWT without installing anything

William Andrews — Sat, 02 May 2026 04:59:58 +0000

You're staring at a string that looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Something in your auth flow is broken. The API is returning 401s, the user session isn't persisting, or someone handed you a token and asked why it isn't working. You need to see what's inside it — right now, without installing a library or setting up a project.

This guide shows you how to decode any JWT instantly in the browser, what every part of the token means, and how to diagnose the most common JWT errors from the decoded contents alone.

The anatomy of a JWT

A JWT is three Base64URL-encoded strings separated by dots. There's no encryption happening at the decoding stage — the payload is readable by anyone who has the token. The signature at the end is what makes tampering detectable, but decoding the contents requires no secret key.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9          ← header
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ  ← payload
.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c  ← signature

The header

The header tells you which algorithm was used to sign the token:

{
  "alg": "HS256",
  "typ": "JWT"
}

Common algorithm values: HS256 (HMAC-SHA256, symmetric), RS256 (RSA-SHA256, asymmetric), ES256 (ECDSA). If you see "alg": "none" — that's a serious red flag. It means the token has no signature and should be rejected by any properly configured server.

The payload

The payload contains claims — key-value pairs that assert things about the user or session:

{
  "sub": "1234567890",
  "name": "John Doe",
  "email": "john@example.com",
  "role": "admin",
  "iat": 1516239022,
  "exp": 1516242622,
  "iss": "https://auth.example.com",
  "aud": "https://api.example.com"
}

The signature

The signature is a hash of the header and payload, signed with the server's secret or private key. You cannot verify it without that key — but you don't need to verify it to read the payload. Decoding and verifying are two separate operations.

Standard claims and what they mean

sub (Subject) — the principal this token is about, typically a user ID. This is what your backend uses to identify who the token belongs to.

iss (Issuer) — who created and signed the token. Often a domain or auth service URL. Your server should validate that this matches the expected issuer.

aud (Audience) — who the token is intended for. A token issued for api.example.com should be rejected by other-api.example.com. Mismatched audience is a common source of 401 errors.

exp (Expiration) — a Unix timestamp after which the token must be rejected. This is the most common reason for 401 errors in production.

iat (Issued At) — when the token was created, as a Unix timestamp. Useful for calculating how old the token is.

nbf (Not Before) — the token must be rejected before this time. Less common, used when tokens are issued in advance.

jti (JWT ID) — a unique identifier for this specific token, used to prevent replay attacks.

How to decode a JWT in the browser right now

Paste the token into DevCrate's JWT Debugger and you'll see the header and payload decoded instantly — no account, no install, nothing sent to a server.

If you prefer to do it in code:

function decodeJwt(token) {
  const parts = token.split('.');
  if (parts.length !== 3) throw new Error('Invalid JWT format');

  const decode = (str) => {
    const base64 = str.replace(/-/g, '+').replace(/_/g, '/');
    const padded = base64.padEnd(base64.length + (4 - base64.length % 4) % 4, '=');
    return JSON.parse(atob(padded));
  };

  return {
    header:  decode(parts[0]),
    payload: decode(parts[1]),
  };
}

const { header, payload } = decodeJwt(token);
console.log(payload.exp); // expiry timestamp
console.log(payload.sub); // user ID

Note what this does and doesn't do: it reads the payload without verifying the signature. Fine for debugging — never use this in place of server-side verification for actual auth decisions.

Diagnosing common JWT errors from the decoded payload

401 — "Token expired"

Check the exp claim. Convert it to a readable date:

new Date(payload.exp * 1000).toLocaleString()
// → "4/30/2026, 11:42:00 PM"

If that date is in the past, the token is expired. The fix is on the client — it needs to refresh the token before it expires or request a new one after receiving a 401.

401 — "Invalid audience"

Check the aud claim. Common mismatches:

Token issued for https://api.example.com, server expects api.example.com (no scheme)
Token issued for staging, hitting production
Token issued for one service being used against a different service
aud is an array and the server is checking for a single string match

401 — "Invalid issuer"

Check the iss claim. Same class of problem as audience mismatch. Common in multi-environment setups where a dev token gets used against a prod server, or when an auth provider URL changes.

403 — "Insufficient permissions"

The token is valid but the user doesn't have access. Look for custom claims in the payload — role, permissions, scope, groups. These are application-specific:

{
  "sub": "user_123",
  "role": "viewer",
  "permissions": ["read"],
  "scope": "openid profile"
}

Token present but user isn't authenticated

Check whether the token is being sent correctly:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

Common mistakes: "Bearer" misspelled or missing, double space between Bearer and the token, or the token has been URL-encoded in transit (look for %2B or %3D in the token string).

Token looks valid but server rejects it

If the header and payload decode cleanly and all claims look correct, the problem is the signature. Possible causes:

Token signed with a different secret than the server is using to verify
Token was modified after signing
Algorithm mismatch — HS256 vs RS256 when switching auth libraries
Clock skew — server's system time is off enough that exp and nbf checks fail

Reading tokens from real-world locations

From browser storage: DevTools → Application → Local Storage or Session Storage → look for keys like token, access_token, auth_token.

From browser cookies: DevTools → Application → Cookies → look for anything with a value starting with ey.

From a network request: DevTools → Network → click a failing request → Headers tab → find the Authorization header → copy the value after "Bearer ".

From curl:

TOKEN=$(curl -s -X POST https://api.example.com/login \
  -H "Content-Type: application/json" \
  -d '{"email":"user@example.com","password":"secret"}' \
  | jq -r '.access_token')
echo $TOKEN

One thing to never do with a JWT debugger

Never paste a production JWT containing real user data into a third-party website. Most online JWT tools send the token to their servers — your token contains claims about real users, and a valid token can be used to make authenticated API calls.

DevCrate's JWT Debugger decodes entirely in the browser using JavaScript — the token never leaves your machine. You can verify this by opening DevTools → Network while using the tool and confirming no requests are made when you paste a token.

URL encoding — what it is, when it breaks, and how to fix it

William Andrews — Tue, 28 Apr 2026 00:23:17 +0000

URL encoding bugs are some of the most frustrating to debug because they're invisible. A string looks fine in your code, but by the time it arrives at the server it's been mangled — spaces became + signs, the & that was part of your data got interpreted as a query string separator, or the whole parameter silently disappeared.

This guide covers how URL encoding works, where it goes wrong, and the exact functions to use in JavaScript and other languages to handle it correctly every time.

What URL encoding actually is

URLs can only contain a specific set of characters safely: letters (A–Z, a–z), digits (0–9), and a handful of special characters (-, _, ., ~). Everything else — spaces, ampersands, equals signs, slashes, non-ASCII characters — needs to be encoded before it can be included in a URL without breaking its structure.

The encoding scheme is called percent-encoding. Each unsafe character is replaced by a percent sign followed by its two-digit hexadecimal ASCII code. A space becomes %20, an ampersand becomes %26, an equals sign becomes %3D, a forward slash becomes %2F.

Hello World   →   Hello%20World
user@example  →   user%40example
price=5&qty=2 →   price%3D5%26qty%3D2
café          →   caf%C3%A9

Non-ASCII characters like accented letters and emoji are first encoded to UTF-8 bytes, then each byte is percent-encoded. That's why café becomes caf%C3%A9 — the é character is two bytes in UTF-8 (0xC3, 0xA9), each percent-encoded.

The two contexts that confuse everyone

URL encoding isn't one thing — it's two different operations applied in two different places, and mixing them up is the root cause of most encoding bugs.

Encoding a full URL

When you have a complete URL and want to make it safe to use as a link or pass to a browser, you want to encode only the characters that are illegal in URLs entirely — but leave the structural characters (:, /, ?, #, &, =) alone, because those are part of the URL's structure.

encodeURI("https://example.com/search?q=hello world&lang=en")
// → "https://example.com/search?q=hello%20world&lang=en"
//   Note: & and = are NOT encoded — they're structural

Encoding a query parameter value

When you're inserting a value into a URL — a search term, a redirect URL, a user-submitted string — you need to encode everything that isn't a plain alphanumeric character, including the structural characters. If your value contains an & and you don't encode it, the browser will interpret it as a parameter separator and split your value in two.

encodeURIComponent("hello world & more")
// → "hello%20world%20%26%20more"
//   Note: & IS encoded as %26 — it's data, not structure

// Building a URL with a parameter
const query = "price < 100 & in stock";
const url = `https://example.com/search?q=${encodeURIComponent(query)}`;
// → "https://example.com/search?q=price%20%3C%20100%20%26%20in%20stock"

The rule: use encodeURI() on complete URLs. Use encodeURIComponent() on individual values being inserted into URLs. Use encodeURIComponent() far more often than encodeURI().

The space problem: %20 vs +

Spaces are the single most common source of URL encoding confusion because there are two valid encodings for them, used in different contexts:

%20 is the standard percent-encoding for a space and works correctly in any part of a URL.

+ represents a space only in the query string of application/x-www-form-urlencoded content — the format HTML forms use when submitted. In a URL path, + is a literal plus sign, not a space.

// These are equivalent in a query string:
https://example.com/search?q=hello+world
https://example.com/search?q=hello%20world

// But in a path, + is literal:
https://example.com/files/hello+world.txt   // file named "hello+world.txt"
https://example.com/files/hello%20world.txt // file named "hello world.txt"

The safe rule: always use %20 for spaces unless you're specifically working with HTML form submissions. Never rely on + outside of form data.

Double-encoding — the silent killer

Double-encoding happens when you encode something that's already encoded. The result looks almost right but is subtly broken:

// Original string
"hello world"

// Encoded once (correct)
"hello%20world"

// Encoded twice (broken — the % itself gets encoded)
"hello%2520world"
//       ↑ %25 is the encoding for %, so %20 became %2520

When the server receives hello%2520world and decodes it once, it gets hello%20world — a string containing a literal percent sign, two, zero. Not the space you intended.

Double-encoding happens most often when:

You encode a value, then pass it through a function that encodes again
You build a URL from already-encoded parts and then encode the whole URL
A framework encodes parameters automatically and you've also encoded them manually
You're constructing a redirect URL where the target URL is itself a query parameter

The fix is to decode first if you're unsure whether something is already encoded:

function safeEncode(str) {
  try {
    return encodeURIComponent(decodeURIComponent(str));
  } catch (e) {
    return encodeURIComponent(str);
  }
}

Characters that have special meaning

Reserved — must be encoded when used as data:

:  %3A    /  %2F    ?  %3F    #  %23
[  %5B    ]  %5D    @  %40    !  %21
$  %24    &  %26    '  %27    (  %28
)  %29    *  %2A    +  %2B    ,  %2C
;  %3B    =  %3D

Unreserved — never need encoding:

A–Z   a–z   0–9   -   _   .   ~

Note that encodeURIComponent() does not encode: A–Z a–z 0–9 - _ . ! ~ * ' ( ). If you need those encoded too (e.g. in an OAuth signature), you'll need to add them manually after encoding.

Decoding URL-encoded strings

decodeURIComponent("hello%20world")       // → "hello world"
decodeURIComponent("caf%C3%A9")           // → "café"
decodeURIComponent("price%3D5%26qty%3D2") // → "price=5&qty=2"

// Handle malformed input safely
function safeDecode(str) {
  try {
    return decodeURIComponent(str);
  } catch (e) {
    return str;
  }
}

URL encoding in other languages

# Python
from urllib.parse import quote, unquote, quote_plus, unquote_plus

quote("hello world")          # → "hello%20world"
quote_plus("hello world")     # → "hello+world"  (form encoding)
unquote("hello%20world")      # → "hello world"

// PHP
urlencode("hello world")      // → "hello+world"  (form encoding)
rawurlencode("hello world")   // → "hello%20world" (RFC 3986)
// Use rawurlencode() for URL paths and components

// Go
import "net/url"
url.QueryEscape("hello world")    // → "hello+world"
url.PathEscape("hello world")     // → "hello%20world"

Encoding a redirect URL as a parameter

One of the trickiest real-world cases — a redirect URL that is itself a query parameter:

// Wrong — the inner ? and & break the outer URL structure
const next = "https://example.com/dashboard?tab=settings&view=list";
const url = `/login?next=${next}`;
// The server sees next=https://example.com/dashboard?tab=settings
// and &view=list as a separate parameter

// Correct — encode the entire redirect URL as a value
const url = `/login?next=${encodeURIComponent(next)}`;
// → /login?next=https%3A%2F%2Fexample.com%2Fdashboard%3Ftab%3Dsettings%26view%3Dlist

Query string construction the right way

Instead of manually encoding and concatenating — which is error-prone — use built-in tools:

// URLSearchParams handles encoding automatically
const params = new URLSearchParams({
  q: "hello world & more",
  lang: "en",
  page: 1
});
console.log(params.toString());
// → "q=hello+world+%26+more&lang=en&page=1"

// Append to a URL
const url = new URL("https://example.com/search");
url.searchParams.set("q", "hello world & more");
url.searchParams.set("lang", "en");
console.log(url.toString());
// → "https://example.com/search?q=hello+world+%26+more&lang=en"

// Read parameters safely — already decoded for you
const params = new URL(window.location.href).searchParams;
const query = params.get("q");

Common encoding bugs and their fixes

Parameter value contains & and gets split — you're not encoding the value before inserting it. Use encodeURIComponent() on the value.

Spaces arrive at the server as literal + — you're using form encoding (+) in a context that expects percent-encoding. Switch to encodeURIComponent().

%25 appears where %20 should be — double-encoding. Find where you're encoding already-encoded data and remove the redundant step.

Non-ASCII characters arrive garbled — the string isn't being encoded to UTF-8 before percent-encoding. In JavaScript, encodeURIComponent() always uses UTF-8.

A parameter value is empty on the server — the value contains characters that terminate the parameter without encoding. Encode the value.

URL works in the browser but fails in fetch or curl — browsers are lenient and will often fix malformed URLs automatically. HTTP clients won't. Always encode explicitly when constructing URLs in code.

If you need to quickly encode or decode a URL or string, DevCrate's URL Encoder/Decoder runs entirely in your browser — nothing you paste is sent anywhere.

SQL formatting — a practical guide for developers

William Andrews — Mon, 20 Apr 2026 01:35:27 +0000

SQL is one of the oldest languages developers still write by hand every day. It's also one of the most inconsistently formatted. Open any codebase with more than one contributor and you'll find queries written in four different styles — keywords uppercase in one file, lowercase in another, indentation that made sense to whoever wrote it six months ago but nobody else.

This guide covers the conventions that make SQL readable, why they exist, and how to apply them consistently regardless of which database you're using.

Why formatting matters more in SQL than most languages

Most languages have autoformatters that make style debates irrelevant — Prettier for JavaScript, Black for Python, gofmt for Go. SQL has no universal equivalent. A query can be written in one line or twenty, with keywords uppercase or lowercase, with or without aliases, and the database will execute it identically. The only thing formatting affects is how easy the query is to read, debug, and modify.

That gap matters more for SQL than most languages because SQL queries tend to be long, because they often live in places autoformatters don't reach (migration files, ORM string literals, analytics dashboards, stored procedures), and because a poorly formatted query in a production codebase is genuinely difficult to audit for correctness.

A well-formatted query tells the reader what it's doing before they have to parse it. A poorly formatted one makes them do the parser's job manually.

The core conventions

Uppercase keywords

Capitalize SQL reserved words: SELECT, FROM, WHERE, JOIN, ON, GROUP BY, ORDER BY, HAVING, LIMIT, AS, AND, OR, NOT, IN, IS, NULL, LIKE, BETWEEN, CASE, WHEN, THEN, ELSE, END.

Lowercase everything else: table names, column names, aliases, string literals, function names. This distinction makes keywords visually separate from data — it immediately tells the reader which parts of the query are instructions and which are data references.

-- Hard to scan
select id, first_name, last_name from users where active = true order by last_name;

-- Much clearer
SELECT id, first_name, last_name
FROM users
WHERE active = TRUE
ORDER BY last_name;

One clause per line

Each major clause starts on its own line: SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY, HAVING, LIMIT. This makes the structure of the query immediately visible — you can see at a glance what tables are involved, what conditions apply, and how results are sorted.

SELECT
    u.id,
    u.email,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at >= '2026-01-01'
GROUP BY u.id, u.email
ORDER BY order_count DESC
LIMIT 100;

Indentation

Indent the contents of a clause by four spaces. This applies to the column list after SELECT, to conditions after WHERE when there are multiple, and to subqueries.

SELECT
    id,
    email,
    created_at
FROM users
WHERE
    active = TRUE
    AND role = 'admin'
    AND created_at >= '2026-01-01';

Leading AND / OR

When a WHERE clause has multiple conditions, start each condition with the logical operator at the beginning of the line rather than the end. This makes it trivial to comment out individual conditions during debugging.

-- Trailing AND — hard to comment out individual conditions
WHERE active = TRUE AND
      role = 'admin' AND
      created_at >= '2026-01-01'

-- Leading AND — easy to comment out individual conditions
WHERE active = TRUE
  AND role = 'admin'
  AND created_at >= '2026-01-01'

Explicit column lists

SELECT * is fine for exploratory queries at a REPL or in a migration test. It should never appear in production application code. Explicit column lists make queries self-documenting, prevent breakage when columns are added to a table, and avoid fetching data you don't need.

-- Never in production code
SELECT * FROM users;

-- What the query actually needs
SELECT id, email, role, created_at FROM users;

Table aliases

Use short, meaningful aliases when joining multiple tables. Always define the alias in the FROM or JOIN clause and use it consistently throughout.

SELECT
    u.id,
    u.email,
    p.plan_name,
    p.expires_at
FROM users u
INNER JOIN subscriptions s ON s.user_id = u.id
INNER JOIN plans p ON p.id = s.plan_id
WHERE s.status = 'active';

Formatting JOINs

Each JOIN and its ON condition go on separate lines. The join type should always be written explicitly — never just JOIN, which defaults to INNER JOIN and hides intent. When the ON condition spans multiple columns, each condition gets its own line:

FROM orders o
INNER JOIN users u ON u.id = o.user_id
LEFT JOIN coupons c ON c.id = o.coupon_id
LEFT JOIN order_items oi
    ON oi.order_id = o.id
    AND oi.deleted_at IS NULL;

Subqueries

Indent subqueries by four spaces relative to the outer query. The opening parenthesis stays on the same line as the clause it belongs to; the closing parenthesis goes on its own line.

SELECT
    u.id,
    u.email,
    (
        SELECT COUNT(*)
        FROM orders o
        WHERE o.user_id = u.id
          AND o.status = 'completed'
    ) AS completed_order_count
FROM users u
WHERE u.active = TRUE;

For subqueries in a WHERE clause:

WHERE u.id IN (
    SELECT user_id
    FROM subscriptions
    WHERE status = 'active'
      AND expires_at > NOW()
)

CTEs — Common Table Expressions

CTEs (WITH clauses) are one of the most underused SQL features for readability. Instead of nesting subqueries three levels deep, you name each logical step and reference it by name. Format each CTE with the name and AS on the first line, the query indented inside the parentheses, and each CTE separated by a comma and a blank line.

WITH active_users AS (
    SELECT id, email, created_at
    FROM users
    WHERE active = TRUE
      AND role != 'guest'
),

recent_orders AS (
    SELECT user_id, COUNT(*) AS order_count
    FROM orders
    WHERE created_at >= NOW() - INTERVAL '30 days'
    GROUP BY user_id
)

SELECT
    u.id,
    u.email,
    COALESCE(o.order_count, 0) AS orders_last_30_days
FROM active_users u
LEFT JOIN recent_orders o ON o.user_id = u.id
ORDER BY orders_last_30_days DESC;

CTEs don't just improve formatting — they change how you write queries. When you can name a logical step, you start thinking in terms of "first get active users, then find their recent orders, then join them" rather than writing the whole thing inside-out as nested subqueries.

CASE expressions

Format CASE expressions with each WHEN and the ELSE on its own indented line, and END at the same indentation level as CASE:

SELECT
    id,
    email,
    CASE
        WHEN subscription_tier = 'pro' THEN 'Pro user'
        WHEN subscription_tier = 'team' THEN 'Team member'
        WHEN trial_expires_at > NOW() THEN 'Trial'
        ELSE 'Free'
    END AS user_type
FROM users;

Comments

Use -- for single-line comments and /* */ for multi-line blocks. Comments in SQL are especially valuable because queries often encode business logic that isn't obvious from the SQL itself.

-- Exclude soft-deleted records and internal test accounts
WHERE deleted_at IS NULL
  AND email NOT LIKE '%@devcrate.net'

/*
  This CTE handles the edge case where a user can have
  multiple active subscriptions during a plan change window.
  We take the most recently created one.
*/

Dialect differences worth knowing

The conventions above apply across PostgreSQL, MySQL, SQLite, and SQL Server. A few syntax differences are worth knowing:

String quoting: Standard SQL uses single quotes for strings. MySQL also accepts double quotes by default, but this is non-standard and should be avoided. PostgreSQL uses single quotes strictly.

Identifier quoting: PostgreSQL uses double quotes ("My Column"). MySQL uses backticks (`My Column`). SQL Server uses square brackets ([My Column]). Avoid column or table names that require quoting entirely — it adds noise to every query that references them.

LIMIT vs TOP vs FETCH: PostgreSQL, MySQL, and SQLite use LIMIT n. SQL Server uses SELECT TOP n. Standard SQL uses FETCH FIRST n ROWS ONLY.

Date functions: Date arithmetic varies significantly. NOW() works in PostgreSQL and MySQL. SQLite uses datetime('now'). INTERVAL syntax also differs. This is one of the most common sources of queries that work in development but break in production when the databases differ.

A formatter won't replace judgment

Autoformatters are useful — they eliminate whitespace debates and catch obvious inconsistencies. But SQL formatting judgment goes beyond what a formatter can enforce. Knowing when to use a CTE vs a subquery, when to break a long condition across multiple lines, when an alias adds clarity vs noise — these require understanding the query, not just the syntax.

The goal of formatting is to make the query's intent legible to someone reading it cold. A query that passes a linter but buries its logic in three levels of nested subqueries with cryptic single-letter aliases hasn't achieved that goal.

If you want to format an existing query quickly, DevCrate's SQL Formatter runs entirely in your browser — paste any query and it applies consistent indentation and keyword casing. Nothing leaves your machine.

Regex cheat sheet for developers — patterns you'll actually use

William Andrews — Wed, 15 Apr 2026 22:27:44 +0000

Regex is one of those things that's extremely useful once you have it, and extremely easy to forget the moment you stop using it. Most developers don't need to memorize the full syntax — they need a reference they trust that they can grab patterns from quickly.

This post is that reference. Every pattern here is real, tested, and explained. At the bottom there's a link to DevCrate's Regex Studio where you can paste any pattern and test it against your own input immediately.

Quick syntax refresher

Before the patterns — a brief reminder of the building blocks.

.        any character except newline
\d       digit (0–9)
\D       non-digit
\w       word character (a-z, A-Z, 0-9, _)
\W       non-word character
\s       whitespace (space, tab, newline)
\S       non-whitespace
^        start of string
$        end of string
\b       word boundary
[abc]    character class: a, b, or c
[^abc]   negated class: not a, b, or c
[a-z]    range: a through z
(abc)    capture group
(?:abc)  non-capturing group
a|b      alternation: a or b

Quantifiers
*        0 or more (greedy)
+        1 or more (greedy)
?        0 or 1
{n}      exactly n
{n,}     n or more
{n,m}    between n and m
*?       0 or more (lazy)
+?       1 or more (lazy)

Flags (JavaScript)
i        case-insensitive
g        global (find all matches)
m        multiline (^ and $ match line start/end)
s        dotAll (. matches newline too)

Email addresses

There is no single "correct" email regex — the RFC is notoriously complex and full email validation is best left to a library or a confirmation link. For most use cases, you need something that catches obvious mistakes without being too strict.

// Practical — catches most real addresses
/^[^\s@]+@[^\s@]+\.[^\s@]+$/

// Stricter — requires valid TLD characters, no consecutive dots
/^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/

The first pattern reads as: one or more characters that aren't whitespace or @, then @, then the same again, then a dot, then the same again. It'll catch user@example.com, user+tag@sub.domain.io, and will correctly reject notanemail and @nodomain.

URLs

// Match http/https URLs
/https?:\/\/[^\s/$.?#].[^\s]*/i

// Match any URL including bare domains
/(?:https?:\/\/)?(?:www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b(?:[-a-zA-Z0-9()@:%_+.~#?&/=]*)/i

// Extract just the domain from a full URL
/(?:https?:\/\/)?(?:www\.)?([^\/\s?#]+)/i
// → match[1] is the domain

URL regex is notoriously tricky. For most validation tasks — form input, user-submitted links — it's often cleaner to use new URL(input) in JavaScript and catch the error if it's invalid. The regex above is best used for extracting URLs from arbitrary text, not strict validation.

Phone numbers

// US phone — accepts (555) 555-5555, 555-555-5555, 5555555555
/^[\+]?[(]?[0-9]{3}[)]?[-\s\.]?[0-9]{3}[-\s\.]?[0-9]{4,6}$/

// International — starts with + and country code
/^\+?[1-9]\d{6,14}$/

// Strip all non-digits before matching (recommended)
const digits = phone.replace(/\D/g, '');
/^\d{10}$/.test(digits); // US number

The strip-then-match approach is usually the most practical. Users enter phone numbers in too many formats to catch them all with a single pattern — normalizing first makes the validation much simpler.

Dates

// ISO 8601 — 2026-04-15
/^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$/

// US format — 04/15/2026
/^(0[1-9]|1[0-2])\/(0[1-9]|[12]\d|3[01])\/\d{4}$/

// Any separator — 2026-04-15 or 2026/04/15 or 2026.04.15
/^\d{4}[\/\-\.](0[1-9]|1[0-2])[\/\-\.](0[1-9]|[12]\d|3[01])$/

These patterns validate format but not logical validity — they'll accept February 31st. For actual date validation, parse with new Date() and check isNaN(), or use a library like date-fns.

IP addresses

// IPv4 — matches 0.0.0.0 to 255.255.255.255
/^(25[0-5]|2[0-4]\d|[01]?\d\d?)(\.(25[0-5]|2[0-4]\d|[01]?\d\d?)){3}$/

// IPv6 — full address
/^([0-9a-fA-F]{1,4}:){7}[0-9a-fA-F]{1,4}$/

The IPv4 pattern is worth understanding: 25[0-5] matches 250–255, 2[0-4]\d matches 200–249, and [01]?\d\d? matches 0–199.

URL slugs

// Validate a slug — lowercase letters, numbers, hyphens only
/^[a-z0-9]+(?:-[a-z0-9]+)*$/

// Generate a slug from a title
function slugify(str) {
  return str
    .toLowerCase()
    .trim()
    .replace(/[^\w\s-]/g, '')   // remove non-word chars
    .replace(/[\s_-]+/g, '-')   // spaces/underscores → hyphens
    .replace(/^-+|-+$/g, '');   // trim leading/trailing hyphens
}

Password rules

// At least 8 chars, one uppercase, one lowercase, one digit
/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d).{8,}$/

// At least 8 chars, one uppercase, one lowercase, one digit, one special char
/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&\-_#^])[A-Za-z\d@$!%*?&\-_#^]{8,}$/

// Check individual rules (more user-friendly)
const rules = {
  minLength:   str => str.length >= 8,
  hasUpper:    str => /[A-Z]/.test(str),
  hasLower:    str => /[a-z]/.test(str),
  hasDigit:    str => /\d/.test(str),
  hasSpecial:  str => /[@$!%*?&\-_#^]/.test(str),
};

The individual rules approach is friendlier for UI — it lets you show a green checkmark per rule as the user types rather than a single pass/fail.

Hex colors

// 3 or 6 digit hex with #
/^#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})$/

// 3, 4, 6, or 8 digit (includes alpha channel)
/^#([A-Fa-f0-9]{3,4}|[A-Fa-f0-9]{6}|[A-Fa-f0-9]{8})$/

// Extract hex colors from a CSS file
/(?<![a-zA-Z])#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})\b/g

Common code patterns

// UUID v4
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i

// JWT — three base64url segments separated by dots
/^[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+\.[A-Za-z0-9\-_]+$/

// Hex string (any length)
/^[0-9a-fA-F]+$/

// Alphanumeric with underscores and hyphens (good for IDs/usernames)
/^[a-zA-Z0-9_\-]+$/

Extracting things from text

// Extract all URLs from text
const urls = text.match(/https?:\/\/[^\s]+/g) || [];

// Extract all hashtags
const tags = text.match(/#[a-zA-Z]\w*/g) || [];

// Extract all @mentions
const mentions = text.match(/@[a-zA-Z0-9_]+/g) || [];

// Extract all numbers (including decimals and negatives)
const numbers = text.match(/-?\d+(?:\.\d+)?/g) || [];

// Find duplicate words
/\b(\w+)\s+\1\b/gi

Lookaheads and lookbehinds

These let you match something based on what comes before or after it, without including that context in the match.

// Lookahead: match "price" only if followed by a digit
/price(?=\s*\d)/i

// Negative lookahead: match "http" only if NOT followed by "s"
/http(?!s)/

// Lookbehind: match digits only if preceded by "$"
/(?<=\$)\d+(\.\d{2})?/

// Practical: extract value from "amount: 42.50"
const match = text.match(/(?<=amount:\s*)\d+(\.\d+)?/i);
const amount = match ? parseFloat(match[0]) : null;

Lookbehinds are supported in modern JavaScript (Node 10+, Chrome 62+, Safari 2019+). If you need older browser support, use capture groups instead.

A few things worth remembering

Greedy vs lazy matching trips people up constantly. .* is greedy — it matches as much as possible. .*? is lazy — it stops at the first opportunity. If you're extracting content between tags and getting too much, switching from .* to .*? usually fixes it.

Escaping in strings adds a layer of confusion. In a JavaScript string literal, \d needs to be written as \\d if you're passing the pattern as a string to new RegExp(). In a regex literal (/\d/), no double escaping needed.

Test with real data, not invented examples. Edge cases worth testing every time: empty string, all whitespace, Unicode characters, very long strings, strings with newlines.

Test these patterns in your browser

DevCrate's Regex Studio lets you paste any pattern and test it against real input in your browser — with live match highlighting, capture group inspection, and flag toggles. No install, no account, nothing leaves your machine.

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.