DEV Community: William Andrews

Why I removed the AI behind my dev tools (and kept the features that earned it)

William Andrews — Wed, 03 Jun 2026 00:51:35 +0000

I spent a week adding AI features to my developer tool suite. Natural language to regex. AI-powered SQL query explanations. The kind of features you'd expect in a 2026 product. They worked. Users could finally describe what they wanted in plain English and get a real answer back.

Then I ripped the AI out from under them.

Not the features themselves — some of them are still there, still labeled with the same Pro badge, still doing the same thing from the user's perspective. What changed is what runs behind the input box. The API calls to a remote LLM are gone. The features that survived are now powered by a few hundred lines of client-side pattern matching, and the features that couldn't survive that change are gone entirely.

This is the story of how that decision happened, why I think more solo developers should be making the same call, and the simple framework I now use before adding any new feature.

The setup

I run DevCrate — a suite of 22 browser-based developer tools. JSON formatter, JWT decoder, regex tester, cron builder, that kind of thing. The whole product has one promise: nothing leaves your browser. No accounts, no tracking, no data sent anywhere. You can paste production secrets into the JWT decoder and nothing will phone home.

That promise isn't a marketing line. It's the entire reason the product exists. Every other online dev tool sends your data to their server to process. Most developers don't think about it. The ones who do, want an alternative. That's me, that's my users.

For two months things were going well. Tools were shipping, search traffic was climbing, the project was actually starting to feel like a product. Then I had what felt like a great idea.

The "great" idea

The regex tool was popular but I could see the friction. People landed on it knowing what they wanted to match but not how to write it. "Match email addresses but not the ones with plus signs in them." "Find lines starting with a number followed by a period." Stuff that's trivial to describe and annoying to write as regex.

Solution: add a natural language input. Type the description, get the pattern. Powered by an API call to an LLM behind the scenes. Pro feature. Easy upsell.

Same logic applied to SQL — paste a query, get a plain English explanation. Inherited a 300-line query from a former coworker? Now you understand what it does in 10 seconds. Pro feature, easy upsell.

I built both. They worked. I shipped them. I felt clever.

The realization

A few days after shipping, I was testing the regex tool in the browser and noticed the network tab. The natural-language input was firing a request to api.anthropic.com — failing on CORS, technically, but trying. Every keystroke that triggered the "Generate" button was reaching out across the public internet with whatever the user had typed into the box.

The CORS failure was almost beside the point. The architecture was the problem. I had built a feature that, by design, took user input and sent it to a third party. The fact that it didn't currently succeed because the browser was blocking it was a security accident, not a security feature. The intended path was for that data to leave the machine.

I sat with that for a minute. I had two ways to think about it:

Option A: "Fix" the CORS issue by routing the request through my own Cloudflare Worker. Now the request succeeds. The user's regex description goes to my worker, which forwards it to the LLM, which sends back a pattern. Technically my homepage still says "nothing leaves your browser" because, well, it's only the Pro AI features that send anything anywhere. Everything else is still client-side.

Option B: Notice that the sentence I just wrote contains the word "only" doing a lot of load-bearing work, and that this is exactly how every product that betrays its users' trust talks about itself.

"Only the Pro features." "Only when you opt in." "Only the data we need." "Only to improve the service." Every analytics SDK is "opt-in." Every tracker is "for your benefit." Every data collection feature has a justification that sounds reasonable until you stack them up next to each other.

The whole reason DevCrate exists is that I got tired of products doing that. And here I was, doing that.

What I actually did

Here's the part where most blog posts oversimplify, so I want to be specific. I didn't remove the natural-language regex feature. I removed the AI behind it. There's a difference and it matters.

What got deleted entirely:

The AI SQL query explainer. The whole feature is gone — there's no way to take an arbitrary SQL query and explain it without running it through a model, and I wasn't willing to do that. So that feature died.

What got rewired but kept:

The regex tool's natural-language input. Same input box, same Pro badge, same "Generate →" button. But behind the button is now a function with about 30 hardcoded patterns covering the most common requests (email, phone, UUID, hex color, IPv4, "lines starting with a number," and so on). If your description matches one of them, you get the regex instantly. If it doesn't, you get a message explaining what phrases are supported, plus a link to my contact form pre-filled with what you tried — so I can grow the pattern list based on what real users are actually asking for.
The cron tool's natural-language input. Same treatment. About 15 hardcoded patterns covering common schedules ("every weekday at 9am," "every 15 minutes," "first day of month"). No API call. If it doesn't match, you get a "suggest a pattern" link.

From the user's perspective, the regex and cron features still work for the common cases. The Pro badge is still there. The pitch is still "describe what you want, get the pattern." What's different is that nothing — not a single byte — leaves your browser when you use them. The features got dumber. The product promise got honest again.

I think this distinction is more useful than the version where I claim I "removed AI." A lot of AI features could be replaced with deterministic logic this way. The question isn't whether AI exists in your feature, it's whether AI is doing work a hardcoded function couldn't.

The framework I use now

This wasn't a one-off. Every product has a core promise — the thing you say to yourself and your users that defines what the product is. Privacy-first. Open source. No subscription. Beginner-friendly. Lightning-fast. Whatever it is, your features either reinforce that promise or they erode it.

Before I add any new feature now, I ask three questions:

1. Does this feature still work if I'm honest about what it does?

The test: write the marketing copy for the feature in the most boring, technical, accurate way possible. No spin. If "AI regex generator" becomes "we send your description to a third-party LLM provider and they return a regex pattern" and that statement contradicts something else on my homepage, the feature has a problem. Not necessarily a fatal one — but a problem worth solving before launch.

For the SQL explainer, the honest description was "we send your query to a third-party LLM." That broke the homepage promise. The feature died.

For the regex natural-language input, the honest description became "matches your description against a list of common patterns in your browser." That works fine. The feature lived.

2. What's the dumbest version of this feature that would still be useful?

The AI regex generator was an LLM call. The non-AI version was a 50-line function with hardcoded patterns. The dumb version covered 80% of real user requests, ran instantly, cost nothing, and didn't send a single byte off the user's machine. It wasn't as impressive. It was better for the product.

I'm not anti-AI. I use AI tools every day to build DevCrate. The question isn't whether AI is useful — it's whether this particular feature needs AI to deliver the value, or whether AI is just the impressive-sounding way to ship it.

3. Who benefits if I add this — me or the user?

This one stings. When I shipped the AI features I had a clear story: Pro upsell, modern feature set, market signal that the product is "real." Those are all reasons that benefit me. The user got a feature that mostly already existed in the form of asking ChatGPT directly — except now they were paying me for it.

Features that primarily benefit you (the developer) and only secondarily benefit the user have a way of eroding trust quietly. Users can feel it even when they can't articulate it.

What I'm not saying

I'm not saying don't add AI to your product. Many products genuinely benefit from AI features — that's why the entire industry is moving in that direction. Cursor, GitHub Copilot, Linear's AI features, Claude itself. All of them ship AI that earns its place.

I'm saying: be honest about whether your specific feature does. For a privacy-first browser tool, sending data to a third-party LLM was wrong — even when it was opt-in, even when it was a paid feature, even when the homepage was technically still accurate. For a code editor running on your local machine, calling out to an LLM is fine. The category matters more than the trend.

I'm also not saying I'd never bring real AI back to DevCrate. If I built a feature where the model ran entirely client-side — using something like WebLLM or a small WASM model — that would honor the privacy promise. The technology exists. It's not ready for the use cases I had in mind yet, but it's getting closer. When it's ready, that's a feature worth shipping.

The takeaway

The best moment to catch a feature that contradicts your product is before any user complains about it. Not because users won't notice — they will, eventually — but because by then the trust is already gone. The CORS error that flagged this for me was lucky timing. I'd rather build the kind of habit where I don't need lucky timing.

The version of the lesson I'm taking forward isn't "remove features." It's: separate the feature from the implementation. The AI was the implementation. The pitch was the feature. Some pitches can be kept by swapping the implementation. Some can't. Knowing which is which is most of the work.

The next time you find yourself adding a feature that requires a footnote to explain why it doesn't contradict your product's core promise, stop. Write the footnote. Read it out loud. Decide if you'd believe yourself.

If you wouldn't, your users won't either.

I'm William, the developer behind DevCrate. This is the kind of thing I'd love to talk through with other solo devs — if you've shipped a feature that you later realized fought with your product's core promise, I genuinely want to hear how you handled it.

What feature have you removed (or wished you'd removed) from your product? Drop it in the comments — I read every one.

Base64 explained — what it is, when to use it, and the gotchas that bite developers

William Andrews — Wed, 27 May 2026 19:50:53 +0000

You see a long string of letters and numbers ending in == and wonder what it is. You paste a JWT into a tool and the middle section is mostly readable. You embed an image in an HTML email and the src attribute is a wall of characters. You upload a PDF to an API and the docs tell you to "send it as Base64." They're all the same encoding, and most developers use it without ever really understanding what it does.

This guide covers what Base64 actually is, when you should reach for it, the common mistakes (including the biggest one — assuming it's encryption), URL-safe variants, padding rules, and how to encode and decode it in every major language.

What Base64 actually is

Base64 is an encoding that converts binary data into ASCII text using 64 specific characters: A-Z, a-z, 0-9, plus + and /. The = character is used for padding at the end. Every 3 bytes of input become exactly 4 Base64 characters of output — meaning Base64 increases data size by roughly 33%.

Input bytes:   "Hi"                  (2 bytes: 0x48 0x69)
Binary:        01001000 01101001
Group in 6s:   010010 000110 1001(00)   ← last group padded with zeros
Base64 chars:  S      G      k    =     ← '=' = padding

Result:        "SGk="

The math: 64 characters means each character represents 6 bits. The lowest common multiple of 6 bits (one Base64 char) and 8 bits (one byte) is 24 bits — which is 3 bytes or 4 Base64 chars. That's why Base64 always works in groups of 4 output characters, and why padding exists at all.

The biggest misconception: Base64 is not encryption

This catches developers and non-developers alike. Base64 looks like gibberish, so it feels like a secret. It isn't. Anyone can decode Base64 instantly — there's no key, no password, no algorithm to crack. It's a transparent transformation, like writing in a different alphabet.

// "Encrypted" password?
"cGFzc3dvcmQxMjM="

// Decoded in one line
atob("cGFzc3dvcmQxMjM=")
// → "password123"

Base64 is encoding, not encryption. Use it to transport data safely through text-only channels — never to hide data. If you need confidentiality, use real encryption: AES, NaCl/libsodium, or TLS for data in transit.

When to use Base64

Base64 exists to move binary data through systems that expect text. The most common cases:

Embedding binary in JSON or XML — neither format supports raw bytes. APIs that accept file uploads as part of a JSON payload use Base64 to represent the file.

Data URLs in HTML/CSS — data:image/png;base64,iVBORw0KGgo... lets you embed an image inline without a separate HTTP request. Useful for small icons and email signatures.

HTTP Basic Auth — the Authorization header sends credentials as Basic <base64-of-username:password>. This is also a perfect example of why Base64 isn't encryption — Basic Auth is only secure when paired with HTTPS.

JWTs — JSON Web Tokens consist of three Base64URL-encoded sections separated by dots. The header and payload are readable JSON; only the signature is opaque.

Email attachments — SMTP is technically a 7-bit text protocol, so attachments have been Base64-encoded by default since the MIME standard.

Cryptographic keys and certificates — PEM files (the -----BEGIN CERTIFICATE----- blocks) wrap Base64-encoded binary keys.

Padding — why some Base64 ends in = and some doesn't

The = at the end of Base64 strings is padding. It exists because Base64 works in groups of 3 input bytes, and not every input is a multiple of 3 bytes long. When the input is short by 1 or 2 bytes, the encoder pads the output with = characters so the result is always a multiple of 4 characters.

Input length (mod 3)   Padding   Example
─────────────────────────────────────────
0 (multiple of 3)      none      "Man"  → "TWFu"
1                      ==        "M"    → "TQ=="
2                      =         "Ma"   → "TWE="

Some encoders and protocols strip the padding to save bytes. JWTs do this — the Base64URL encoding inside a JWT has no padding at all. If you're manually decoding Base64 from a JWT, you may need to add the padding back before some decoders will accept it.

// JavaScript: add padding back to an unpadded Base64 string
function pad(b64) {
  const remainder = b64.length % 4;
  return remainder ? b64 + '='.repeat(4 - remainder) : b64;
}

Base64 vs Base64URL — the variant that matters for the web

Standard Base64 uses + and / as its 62nd and 63rd characters. Both have special meaning in URLs: + means "space" in query strings, and / is a path separator. Putting standard Base64 in a URL without further encoding breaks things.

Base64URL (defined in RFC 4648) solves this by swapping those characters: + becomes -, and / becomes _. It also typically omits padding. The result is safe to drop directly into URLs, filenames, and HTTP headers.

Standard Base64:   "abc/d+ef=="
Base64URL:         "abc_d-ef"

// Convert one to the other
const toUrlSafe = (b64) => b64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '');
const fromUrlSafe = (b64u) => {
  const b64 = b64u.replace(/-/g, '+').replace(/_/g, '/');
  return pad(b64); // add padding back
};

JWTs use Base64URL. So do most modern token formats, OAuth state parameters, and anything else that travels in a URL.

Encoding and decoding in JavaScript

JavaScript has two built-in functions: btoa() (binary-to-ASCII, encode) and atob() (ASCII-to-binary, decode). The names are confusing — they don't work the way you'd expect for arbitrary binary data.

// Simple ASCII strings — these work
btoa("Hello, world!");
// → "SGVsbG8sIHdvcmxkIQ=="

atob("SGVsbG8sIHdvcmxkIQ==");
// → "Hello, world!"

// Unicode strings — this BREAKS
btoa("héllo");
// → DOMException: invalid character

// Correct way for Unicode: encode to UTF-8 first
function utf8ToBase64(str) {
  return btoa(unescape(encodeURIComponent(str)));
}
function base64ToUtf8(b64) {
  return decodeURIComponent(escape(atob(b64)));
}

utf8ToBase64("héllo");   // → "aMOpbGxv"
base64ToUtf8("aMOpbGxv"); // → "héllo"

// Modern alternative (Node 16+, modern browsers)
const bytes = new TextEncoder().encode("héllo");
const b64 = btoa(String.fromCharCode(...bytes));

For binary data like file uploads, work with ArrayBuffer or Uint8Array:

// Convert a file to Base64 (browser)
async function fileToBase64(file) {
  const buffer = await file.arrayBuffer();
  const bytes = new Uint8Array(buffer);
  let binary = '';
  for (const byte of bytes) binary += String.fromCharCode(byte);
  return btoa(binary);
}

// FileReader alternative — gives you a data URL
function fileToDataUrl(file) {
  return new Promise(resolve => {
    const reader = new FileReader();
    reader.onload = () => resolve(reader.result);
    reader.readAsDataURL(file);
  });
}

Encoding and decoding in Python

import base64

# Encode a string
encoded = base64.b64encode(b"Hello, world!")
# → b"SGVsbG8sIHdvcmxkIQ=="

# Decode
decoded = base64.b64decode(b"SGVsbG8sIHdvcmxkIQ==")
# → b"Hello, world!"

# URL-safe variant — for JWTs, URLs, filenames
url_safe = base64.urlsafe_b64encode(b"data with /and+chars")
# → b"ZGF0YSB3aXRoIC9hbmQrY2hhcnM="

# Encode a file
with open("photo.jpg", "rb") as f:
    encoded_file = base64.b64encode(f.read()).decode("ascii")

Encoding and decoding on the command line

# macOS and Linux — encode
echo -n "Hello, world!" | base64
# → SGVsbG8sIHdvcmxkIQ==

# Decode
echo "SGVsbG8sIHdvcmxkIQ==" | base64 -d
# → Hello, world!

# Encode a file
base64 photo.jpg > photo.txt

# Decode a file
base64 -d photo.txt > photo.jpg

# Watch out — many systems wrap output at 76 characters by default
# Use -w 0 (GNU) or no flag (BSD) to disable wrapping
echo -n "long content..." | base64 -w 0

Encoding and decoding in SQL

-- PostgreSQL
SELECT encode('Hello, world!'::bytea, 'base64');
-- → SGVsbG8sIHdvcmxkIQ==

SELECT convert_from(decode('SGVsbG8sIHdvcmxkIQ==', 'base64'), 'UTF8');
-- → Hello, world!

-- MySQL 8+
SELECT TO_BASE64('Hello, world!');
-- → SGVsbG8sIHdvcmxkIQ==

SELECT FROM_BASE64('SGVsbG8sIHdvcmxkIQ==');
-- → Hello, world!

Common bugs and how to avoid them

The line-wrap trap. Some implementations (notably MIME and OpenSSL) wrap Base64 output at 64 or 76 characters with newlines. Other implementations reject input that contains newlines. If you're seeing "invalid character" errors decoding what looks like valid Base64, strip whitespace first.

The padding mismatch. JWTs and URL-safe Base64 typically omit padding. Many decoders require it. If decoding fails, calculate how many = characters to add: (4 - (length % 4)) % 4 of them.

The UTF-8 assumption. Base64 encodes bytes, not characters. Encoding a string assumes you know what character encoding it's in. Always make the encoding explicit (UTF-8 is almost always the right answer) and decode back to bytes before treating the result as a string.

The size surprise. Base64 increases payload size by 33%. For small assets it doesn't matter. For a 10 MB file embedded in JSON, it does — you're sending 13.3 MB over the wire. For larger files, prefer multipart uploads.

Treating it as a secret. Worth saying twice: Base64 is not encryption. Don't store passwords, API keys, or other sensitive data as Base64 expecting it to be hidden. If you can see the encoded string, you can see the original.

I'm William, the developer behind DevCrate. The Base64 tool exists because I got tired of dropping pseudo-random strings into shady online converters to see what was inside. It encodes and decodes both standard and URL-safe variants, handles files, and never sends a single byte off your machine.

If there's a Base64 case this guide didn't cover, drop it in the comments — I read every one.

Unix timestamps explained — converting, formatting, and avoiding the common mistakes

William Andrews — Mon, 11 May 2026 00:01:00 +0000

You're reading a database record and there's a column called created_at with a value of 1746835200. Or you're debugging an API response and the timestamp field contains 1746835200000. Or your log file shows 1746835200 and you need to know when that actually happened.

This guide covers everything you need to work with Unix timestamps confidently — what they are, how to convert them in every major language and tool, the timezone trap that catches most developers, the milliseconds-vs-seconds mistake that causes the worst bugs, and a few things worth knowing about where timestamp math breaks down.

What a Unix timestamp actually is

A Unix timestamp is the number of seconds that have elapsed since January 1, 1970 at 00:00:00 UTC. That moment — midnight UTC on January 1st, 1970 — is called the Unix epoch. Every second that passes increments every Unix timestamp by 1.

0           → 1970-01-01 00:00:00 UTC
1000000000  → 2001-09-09 01:46:40 UTC
1700000000  → 2023-11-14 22:13:20 UTC
1746835200  → 2025-05-10 00:00:00 UTC

A few things this definition makes clear: timestamps are always UTC — they don't carry timezone information. They're always an integer (or occasionally a float with sub-second precision). And they're always positive for dates after 1970, negative for dates before.

The name "Unix timestamp" is used interchangeably with "epoch time", "POSIX time", and "Unix time". They all mean the same thing.

Seconds vs milliseconds — the bug that's bitten everyone

This is the single most common timestamp bug. JavaScript's Date.now() returns milliseconds since the epoch. Most Unix utilities and databases use seconds. The difference is a factor of 1000 — if you pass a millisecond timestamp where seconds are expected you get a date ~33,000 years in the future, and if you pass seconds where milliseconds are expected you get a date in early 1970.

// JavaScript — always milliseconds
Date.now()              // 1746835200000 (13 digits)
new Date().getTime()    // 1746835200000 (13 digits)

// To get seconds in JavaScript
Math.floor(Date.now() / 1000)  // 1746835200 (10 digits)

// Quick check: is this seconds or milliseconds?
// 10 digits → seconds (valid until 2286)
// 13 digits → milliseconds
// 16 digits → microseconds

The digit count rule is the fastest way to tell which you're dealing with. A 10-digit timestamp is seconds. A 13-digit timestamp is milliseconds. When you see something in between — 11 or 12 digits — something has gone wrong upstream.

Converting timestamps in JavaScript

// Current timestamp
const nowMs  = Date.now();
const nowSec = Math.floor(Date.now() / 1000);

// Timestamp to Date object
const date       = new Date(1746835200 * 1000); // seconds → multiply by 1000
const dateFromMs = new Date(1746835200000);      // already milliseconds

// Date to timestamp
const ts = Math.floor(new Date('2025-05-10').getTime() / 1000);

// Format a timestamp as a readable string
function formatTimestamp(ts, tz = 'UTC') {
  return new Intl.DateTimeFormat('en-US', {
    timeZone: tz,
    year: 'numeric', month: 'short', day: 'numeric',
    hour: '2-digit', minute: '2-digit', second: '2-digit',
    hour12: false
  }).format(new Date(ts * 1000));
}

formatTimestamp(1746835200, 'UTC');
// → "May 10, 2025, 00:00:00"

formatTimestamp(1746835200, 'America/New_York');
// → "May 09, 2025, 20:00:00"  ← note: different day

Converting timestamps in Python

import datetime, time

# Current timestamp
ts_seconds = int(time.time())
ts_float   = time.time()   # with sub-second precision

# Timestamp to datetime (UTC)
dt_utc = datetime.datetime.fromtimestamp(1746835200, tz=datetime.timezone.utc)
# → datetime(2025, 5, 10, 0, 0, tzinfo=timezone.utc)

# Datetime to timestamp
dt = datetime.datetime(2025, 5, 10, tzinfo=datetime.timezone.utc)
ts = int(dt.timestamp())
# → 1746835200

# Format
print(dt_utc.strftime('%Y-%m-%d %H:%M:%S %Z'))
# → "2025-05-10 00:00:00 UTC"

# Arithmetic
one_day  = datetime.timedelta(days=1)
tomorrow = dt_utc + one_day
ts_tomorrow = int(tomorrow.timestamp())

Converting timestamps in SQL

-- PostgreSQL
SELECT to_timestamp(1746835200);
-- → 2025-05-10 00:00:00+00

SELECT EXTRACT(EPOCH FROM NOW())::bigint;
-- → current Unix timestamp

SELECT to_timestamp(1746835200) AT TIME ZONE 'America/New_York';
-- → 2025-05-09 20:00:00

-- MySQL
SELECT FROM_UNIXTIME(1746835200);
-- → 2025-05-10 00:00:00  (uses server timezone — be careful)

SELECT UNIX_TIMESTAMP(NOW());
-- → current Unix timestamp

-- SQLite
SELECT datetime(1746835200, 'unixepoch');
-- → 2025-05-10 00:00:00

SELECT strftime('%s', 'now');
-- → current Unix timestamp as string

Converting timestamps on the command line

# macOS (BSD date)
date -r 1746835200
# → Sat May 10 00:00:00 UTC 2025

date -r 1746835200 '+%Y-%m-%d %H:%M:%S'
# → 2025-05-10 00:00:00

# Linux (GNU date)
date -d @1746835200
# → Sat May 10 00:00:00 UTC 2025

# Get current timestamp
date +%s

# Python one-liner (works everywhere)
python3 -c "import datetime; print(datetime.datetime.fromtimestamp(1746835200, tz=datetime.timezone.utc))"

The timezone trap

Unix timestamps are always UTC. They contain no timezone information — they're just a count of seconds. The timezone only matters when you convert a timestamp into a human-readable date. This is where most timestamp bugs live.

// This timestamp is midnight UTC on May 10th
const ts = 1746835200;

// In UTC
new Date(ts * 1000).toISOString();
// → "2025-05-10T00:00:00.000Z"  ← May 10th

// In New York (UTC-4 during EDT)
new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'full'
}).format(new Date(ts * 1000));
// → "Friday, May 9, 2025"  ← May 9th — different day

The rule: always be explicit about timezone when converting timestamps to dates. Never rely on the server's local timezone for anything that will be displayed to users or compared across systems. Store timestamps as UTC, convert to user timezone only at the display layer.

Storing timestamps in databases

Two common approaches — integer storage vs native datetime types:

Integer storage — simple, portable, no timezone ambiguity, easy arithmetic. Not human-readable in the database.

Native datetime with timezone — TIMESTAMPTZ in PostgreSQL, DATETIME with explicit UTC in MySQL. Human-readable, supports native date functions. PostgreSQL's TIMESTAMPTZ stores in UTC and converts on output — almost always the right choice.

-- PostgreSQL: always use TIMESTAMPTZ, not TIMESTAMP
CREATE TABLE events (
  id         SERIAL PRIMARY KEY,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
  -- TIMESTAMP (without timezone) stores the value as-is with no timezone context
  -- This is almost always wrong
);

-- Query by date range (PostgreSQL handles timezone conversion)
SELECT * FROM events
WHERE created_at >= '2025-05-10' AT TIME ZONE 'America/New_York'
  AND created_at  < '2025-05-11' AT TIME ZONE 'America/New_York';

Timestamp arithmetic

const oneHour  = 3600;
const oneDay   = 86400;
const oneWeek  = 604800;

const ts = 1746835200;
const tomorrow = ts + oneDay;
const nextWeek = ts + oneWeek;

// Difference between two timestamps
const start = 1746835200;
const end   = 1746921600;
const diffDays = (end - start) / 86400;  // 1.0

// Is this timestamp in the past?
const isPast = ts < Math.floor(Date.now() / 1000);

// Is this timestamp within the last 24 hours?
const isRecent = (Math.floor(Date.now() / 1000) - ts) < 86400;

One thing to be careful with: "add one month" is ambiguous. Adding 2,592,000 seconds (30 days) to January 31st gives you March 2nd, not February 28th. If calendar-accurate month arithmetic matters, use a library like date-fns or Temporal rather than raw seconds.

ISO 8601 — the timestamp format you should be using in APIs

When exchanging timestamps between systems, don't use raw Unix timestamps. Use ISO 8601 with an explicit timezone offset.

// Bad — ambiguous
"created_at": 1746835200

// Better — but still requires knowing it's seconds vs milliseconds
"created_at": "2025-05-10 00:00:00"

// Best — ISO 8601 with UTC offset, unambiguous
"created_at": "2025-05-10T00:00:00Z"
"created_at": "2025-05-09T20:00:00-04:00"  // same moment, NY local time

// JavaScript
new Date(1746835200 * 1000).toISOString();
// → "2025-05-10T00:00:00.000Z"

// Python
datetime.datetime.fromtimestamp(1746835200, tz=datetime.timezone.utc).isoformat();
// → "2025-05-10T00:00:00+00:00"

The Y2K38 problem

Unix timestamps stored as 32-bit signed integers will overflow on January 19, 2038 at 03:14:07 UTC. At that moment the value exceeds the maximum positive 32-bit integer (2,147,483,647) and wraps to a large negative number — interpreted as a date in 1901.

Most modern systems use 64-bit integers, which won't overflow for approximately 292 billion years. If you're working with legacy systems or embedded hardware that stores timestamps as 32-bit values, this is worth checking. New code should always use 64-bit integers.

// 32-bit max timestamp
new Date(2147483647 * 1000).toISOString()
// → "2038-01-19T03:14:07.000Z"

// One second later in a 32-bit signed system: wraps to -2147483648
new Date(-2147483648 * 1000).toISOString()
// → "1901-12-13T20:45:52.000Z"

If you need to convert a timestamp quickly, DevCrate's Timestamp Converter handles seconds and milliseconds automatically, lets you pick any timezone, and converts in both directions — all in the browser with nothing sent anywhere.

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