Forem: Snappy Tools

JWTs Explained: What's Inside That Token and How to Read It

Snappy Tools — Tue, 26 May 2026 10:13:25 +0000

JWTs Explained: What's Inside That Token and How to Read It

If you've built any web app with authentication in the last five years, you've almost certainly used JWTs (JSON Web Tokens) — even if you didn't realise what was happening under the hood.

They appear in Authorization: Bearer <token> headers, in cookies, in URL parameters. They're the backbone of OAuth 2.0, OpenID Connect, and most modern single-sign-on systems.

But many developers treat them as opaque blobs. You get a JWT from your auth server, you forward it to the API, it works. Magic.

The problem: when something breaks — expired token, wrong claims, missing roles — you're stuck. You don't know what's in the token, so you can't debug it.

This guide will show you exactly what's inside a JWT and how to read one in seconds.

What is a JWT?

A JWT is a compact, URL-safe string made of three Base64URL-encoded parts, separated by dots:

header.payload.signature

Here's a real example:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

That looks like gibberish. But it's just three pieces of JSON, encoded in Base64URL.

Part 1: The Header

Decode the first segment (eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9) from Base64 and you get:

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

The header tells you:

alg: The signing algorithm — HS256 (HMAC-SHA256), RS256 (RSA-SHA256), or ES256 (ECDSA). This matters for verification.
typ: Always JWT.

Security note: The alg: none attack is real. A malicious actor can craft a JWT with "alg": "none" and no signature. Your server should explicitly reject this.

Part 2: The Payload

Decode the second segment and you get the actual data — called claims:

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Claims are categorised as:

Registered claims (standardised, optional but recommended):
| Claim | Full name | Meaning |
|-------|-----------|---------|
| iss | Issuer | Who created this token |
| sub | Subject | Who this token is about (usually a user ID) |
| aud | Audience | Who should accept this token |
| exp | Expiration | Unix timestamp when the token expires |
| iat | Issued at | Unix timestamp when the token was created |
| nbf | Not before | Token is not valid before this time |
| jti | JWT ID | Unique identifier for this token |

Public claims: Custom claims you define, like role, permissions, email.

Private claims: Application-specific claims shared between parties.

The exp claim is the most important for debugging. If it's in the past, your token has expired.

Part 3: The Signature

The third part is a cryptographic signature of header + "." + payload, using the algorithm specified in the header.

This part cannot be decoded to meaningful data — it's binary. But it's crucial:

It proves the token wasn't tampered with
It can only be verified by the party that has the secret key (for HS256) or the public key (for RS256/ES256)

Key point: You can read the header and payload without any key. But you cannot verify the signature without the server's key. Never trust a JWT's contents for security decisions on the client side — always verify server-side.

How to Decode a JWT Instantly

The fastest way: paste your JWT into the SnappyTools JWT Decoder.

It shows you:

Decoded header and payload (pretty-printed JSON)
Expiry countdown (how many seconds until the token expires, or how long ago it expired)
All iat, exp, nbf timestamps converted to human-readable dates
Whether the token is expired or valid

No key required to decode — only to verify.

Debugging JWT Issues: Common Problems

"Token expired"
Check the exp claim. Convert it from Unix timestamp to a date. If it's in the past, your client isn't refreshing tokens properly.

"Invalid audience"
Check the aud claim against what your server expects. A token issued for api.yourapp.com will be rejected by admin.yourapp.com if they check aud.

"Insufficient permissions"
Look for custom claims like role, scope, or permissions. Make sure the issuing server is adding them.

"Signature verification failed"
This usually means the secret/key used to sign the token doesn't match what the server is using to verify. Check for key rotation events.

JWTs vs Session Tokens

	JWT	Session Token
Storage	Client (localStorage, cookie)	Server-side (database)
Verification	Cryptographic (stateless)	Database lookup (stateful)
Revocation	Hard (must wait for expiry)	Easy (delete from DB)
Scalability	Excellent	Requires shared session store
Payload	Carries user data	Just an ID

JWTs shine for microservices and APIs where you don't want every service to call a session database. The trade-off: you can't invalidate a JWT before it expires (without additional infrastructure like a blocklist).

Security Best Practices

Set short expiry times — 15 minutes for access tokens, longer for refresh tokens
Always verify the signature server-side — never trust a JWT just because it decodes
Validate the aud and iss claims — don't accept tokens from unknown issuers
Reject alg: none — explicitly whitelist allowed algorithms
Never store sensitive data in the payload — it's readable by anyone
Use HTTPS always — JWTs in transit can be intercepted
Implement token refresh — short-lived access tokens + refresh tokens

Key Takeaway

A JWT is just a signed JSON object. The signature prevents tampering, but the contents are readable by anyone who has the token.

Next time you need to debug an auth issue, paste the token into a JWT decoder and read it — it'll tell you exactly what's happening.

SnappyTools JWT Decoder — decode any JWT token in your browser. See header, payload, expiry countdown, and human-readable timestamps instantly. 100% private — your token never leaves your browser.

JSON Schema Explained: Validate Your API Data Before It Breaks Production

Snappy Tools — Mon, 25 May 2026 10:07:19 +0000

You've seen this before: a frontend sends a request, the backend crashes, and the logs say TypeError: Cannot read properties of undefined. The payload was missing a required field, or a number arrived as a string. JSON Schema exists precisely to stop this class of bugs before they reach production.

This guide explains what JSON Schema is, how to write one, and how to validate JSON data against it — right in your browser.

What Is JSON Schema?

JSON Schema is a vocabulary that describes the structure of JSON data. It's itself written in JSON and defines:

What fields are required
What type each field should be (string, number, boolean, array, object, null)
Constraints like minimum/maximum values, pattern matching, and array lengths
Nested object structures

Think of it as a contract between a data producer (your API, your database, your user input) and a data consumer (your backend, your frontend, your analytics pipeline).

A Minimal Example

Here's a schema for a user profile object:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "email", "age"],
  "properties": {
    "id": {
      "type": "string",
      "description": "UUID v4 identifier"
    },
    "email": {
      "type": "string",
      "format": "email"
    },
    "age": {
      "type": "integer",
      "minimum": 0,
      "maximum": 150
    },
    "name": {
      "type": "string",
      "maxLength": 100
    }
  }
}

And here's JSON that validates against it:

{
  "id": "550e8400-e29b-41d4-a716-446655440000",
  "email": "user@example.com",
  "age": 28,
  "name": "Alex"
}

This JSON would fail validation:

{
  "id": 12345,
  "age": "twenty-eight"
}

Two errors: id should be a string, age should be an integer (and email is missing entirely).

Core JSON Schema Keywords

`type`

The most fundamental constraint. Allowed values: string, number, integer, boolean, array, object, null.

{ "type": "string" }
{ "type": ["string", "null"] }  // nullable field

`required`

An array of property names that must be present in the object.

{
  "type": "object",
  "required": ["username", "password"]
}

`properties`

Defines the schema for each named property.

String constraints

{
  "type": "string",
  "minLength": 8,
  "maxLength": 64,
  "pattern": "^[a-zA-Z0-9_]+$"
}

Number constraints

{
  "type": "number",
  "minimum": 0,
  "maximum": 100,
  "multipleOf": 0.01
}

Array constraints

{
  "type": "array",
  "items": { "type": "string" },
  "minItems": 1,
  "maxItems": 10,
  "uniqueItems": true
}

`enum`

Restricts a field to a specific set of allowed values:

{
  "type": "string",
  "enum": ["draft", "published", "archived"]
}

Nested Objects

Schemas can describe deeply nested structures. Here's an order item:

{
  "type": "object",
  "required": ["orderId", "items", "total"],
  "properties": {
    "orderId": { "type": "string" },
    "items": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["sku", "quantity"],
        "properties": {
          "sku": { "type": "string" },
          "quantity": { "type": "integer", "minimum": 1 },
          "price": { "type": "number", "minimum": 0 }
        }
      }
    },
    "total": { "type": "number", "minimum": 0 }
  }
}

Schema Composition: `allOf`, `anyOf`, `oneOf`

JSON Schema lets you combine schemas:

allOf — the data must be valid against all listed schemas
anyOf — the data must be valid against at least one
oneOf — the data must be valid against exactly one

{
  "oneOf": [
    { "type": "string", "maxLength": 5 },
    { "type": "number", "minimum": 0 }
  ]
}

This accepts either a short string or a non-negative number — but not both.

Where to Use JSON Schema

API validation — Validate request bodies before processing them. Libraries like ajv (Node.js) and jsonschema (Python) implement the full spec.

Configuration files — Many tools (VS Code, Prettier, ESLint) use JSON Schema to provide autocomplete and validation in config files.

Database documents — MongoDB supports JSON Schema validation natively in collection rules.

CI pipelines — Validate data files, API responses, or config changes as part of your build.

OpenAPI/Swagger — OpenAPI 3.x uses JSON Schema to describe request and response bodies. Understanding JSON Schema means understanding your API docs.

Validate JSON Against a Schema Right Now

Instead of setting up a library locally, you can paste your JSON and schema into the JSON Schema Validator on SnappyTools — it runs entirely in your browser using the ajv library (the most compliant validator available), supports JSON Schema draft-07 and 2020-12, and gives you line-by-line error messages.

Useful when you're:

Debugging why a payload is failing validation
Testing a schema you're writing for the first time
Checking a third-party API response against expected structure

Quick Reference

Keyword	Purpose
`type`	Data type constraint
`required`	Mandatory properties
`properties`	Property schemas
`enum`	Allowed values list
`minimum` / `maximum`	Number range
`minLength` / `maxLength`	String length
`pattern`	Regex constraint on string
`items`	Schema for array elements
`minItems` / `maxItems`	Array length
`allOf` / `anyOf` / `oneOf`	Schema composition
`$ref`	Reference to another schema

Conclusion

JSON Schema is one of those tools that feels like extra work until the first time it catches a production bug before it ships. A well-written schema documents your data structure, validates it automatically, and gives teammates a clear contract to code against.

Start with type and required, then add constraints as needed. Use the online validator to test as you go.

SnappyTools builds free, fast, browser-based tools for developers. No signup, no data uploaded.

JavaScript Minification Explained: How Terser Shrinks Your Code (and Why It Matters)

Snappy Tools — Sun, 24 May 2026 10:09:49 +0000

Every millisecond counts on the web. A 200KB JavaScript bundle takes measurably longer to parse and execute than a 60KB one — and the difference shows up directly in your Core Web Vitals scores. Minification is the fastest, lowest-effort way to close that gap.

Here's exactly what happens under the hood, and how you can do it for free in your browser right now.

What JavaScript Minification Actually Does

Minification is not compression. Compression (gzip, Brotli) happens at the network layer. Minification happens at the source level — it rewrites your code to say the same thing in fewer characters.

A modern minifier like Terser applies several transformations:

1. Whitespace and comment removal

The obvious step. Every space, tab, newline, and comment that isn't inside a string literal gets stripped. On a typical file, this alone saves 20–30%.

// Before
function greet(name) {
  // Say hello
  return "Hello, " + name + "!";
}

// After
function greet(name){return"Hello, "+name+"!"}

2. Name mangling

This is where serious savings happen. Terser renames local variables and function parameters to single characters — a, b, c, and so on. The renamed code is semantically identical but much shorter.

// Before
function calculateDiscountedPrice(originalPrice, discountPercentage) {
  const discountAmount = originalPrice * (discountPercentage / 100);
  return originalPrice - discountAmount;
}

// After (mangled)
function a(b,c){const d=b*(c/100);return b-d}

On large codebases with descriptive variable names, mangling can reduce size by an additional 15–25%.

3. Dead code elimination

Terser removes code paths that can never be reached:

// Before
const DEBUG = false;
if (DEBUG) {
  console.log("This never runs");
}
doRealWork();

// After
doRealWork();

4. Constant folding

Mathematical expressions evaluated at compile time:

// Before
const SECONDS_PER_DAY = 60 * 60 * 24;

// After
const SECONDS_PER_DAY = 86400;

5. Syntax simplification

Terser rewrites verbose patterns into shorter equivalents:

// Before
if (x === true) { return true; } else { return false; }

// After
return x === true;
// Or even: return x;  (if x is already boolean)

ES6+ Support: Why Terser Replaced UglifyJS

The original UglifyJS only understood ES5. That meant to minify modern JavaScript, you had to first transpile ES6+ down to ES5 with Babel, then run UglifyJS — two tools, two steps, two chances for bugs.

Terser is a fork of UglifyJS that natively understands:

Arrow functions
Template literals
Destructuring
async/await
Classes
Optional chaining (?.)
Nullish coalescing (??)

No pre-transpilation needed. You can minify modern code directly.

Typical Results

Here are real-world compression ratios from running Terser on common files:

File	Original	Minified	Savings
React (dev)	1,386 KB	419 KB	70%
Lodash 4	532 KB	71 KB	87%
Moment.js	173 KB	66 KB	62%
Simple utility module	8 KB	2.5 KB	69%

Combined with gzip (which all modern servers apply), a minified bundle compresses even further than an unminified one — because repetitive short names gzip better than long variable names.

When NOT to Mangle Names

Mangling breaks code that relies on Function.name or accesses properties by string. If your code does:

class MyService { ... }
container.register(MyService.name, MyService);
// MyService.name is now "a" — breaks DI containers

You can selectively disable mangling for class names or use Terser's keep_classnames: true option.

How to Minify Without a Build Pipeline

You don't need webpack, Vite, or Rollup to minify a file. The fastest way for a quick script or standalone tool page is to paste it directly into an online minifier.

SnappyTools JS Minifier & Beautifier runs Terser entirely in your browser — no code is sent to any server, no account needed. Paste, click, copy.

It also works in reverse: if you need to read minified third-party code, the beautify tab reformats it back to readable indentation.

The Flip Side: Beautification

You'll sometimes encounter minified JavaScript you need to understand — a vendor bundle, a legacy script without source maps, or obfuscated analytics code.

A beautifier reintroduces whitespace and newlines to make the code readable again. It can't recover original variable names (those are gone forever after mangling), but it makes the structure comprehensible.

Practical Workflow

For a quick standalone script:

Write your code in normal, readable form
Paste into a minifier before deploying
Keep the original source file — never edit the minified output

For a build pipeline:

Add terser as a dev dependency
Configure your bundler (webpack TerserPlugin, Vite's built-in minification) to run on production builds
Use source maps so DevTools can show the original code despite minification

Conclusion

Minification is one of the highest-ROI performance optimisations available. A 60-70% reduction in bundle size with zero changes to functionality, applied in seconds. Terser handles modern JavaScript natively, and with browser-based tools, there's no reason to skip it even for quick projects.

Try it on your next script: snappytools.app/javascript-minifier-beautifier

URL Encoding Explained: Why Special Characters Break Your URLs (and How to Fix It)

Snappy Tools — Fri, 22 May 2026 10:12:38 +0000

You paste a URL into your browser and it works fine. You programmatically construct the same URL in code, add a parameter value with a space or ampersand in it, and suddenly the request breaks or returns unexpected results.

URL encoding — also called percent encoding — is why. Here's what it is, when you need it, and how to apply it correctly.

What Is URL Encoding?

URLs can only contain a limited set of characters defined in RFC 3986: letters (A–Z, a–z), digits (0–9), and a handful of special characters (-, _, ., ~). Everything else must be encoded.

Encoding works by replacing the character with a % followed by its two-digit hexadecimal ASCII code.

Character	Encoded
Space	`%20`
`&`	`%26`
`=`	`%3D`
`+`	`%2B`
`/`	`%2F`
`?`	`%3F`
`#`	`%23`
`@`	`%40`

So a URL like:

https://example.com/search?q=hello world&sort=date+desc

becomes:

https://example.com/search?q=hello%20world&sort=date%2Bdesc

Reserved vs Unreserved Characters

The tricky part: some characters have special meaning in the URL structure itself and some are just general-purpose.

Reserved characters (!, *, ', (, ), ;, :, @, &, =, +, $, ,, /, ?, #, [, ]) — they can appear in a URL unencoded when used for their structural purpose (e.g., / separates path segments, ? starts the query string). When they appear as data inside a parameter value, they must be encoded.

Unreserved characters (A–Z, a–z, 0–9, -, _, ., ~) — these never need encoding.

This is the source of most bugs: a / in a path segment is fine. A / inside a query parameter value must be %2F.

The `+` vs `%20` Trap

There are two URL encoding specifications in common use:

RFC 3986 (standard URL encoding): encodes space as %20. Use this for full URLs, path segments, and modern API requests.

application/x-www-form-urlencoded (HTML form encoding): encodes space as +. This is what HTML forms and jQuery's $.ajax() use by default.

Mixing them causes bugs. If your backend expects form encoding and you send %20, the %20 gets through fine (most decoders handle both). But if you encode a literal + as + when you mean a plus sign, the decoder interprets it as a space.

The safest rule: use %20 for spaces in all contexts except traditional HTML form submissions. Never rely on + in API parameters.

How to Encode URLs in Code

JavaScript:

// Encode a full URL component (query parameter value)
const query = encodeURIComponent('hello world & more');
// → 'hello%20world%20%26%20more'

// Encode a full URL while preserving structural characters (/, ?, &, =)
const url = encodeURI('https://example.com/search?q=hello world');
// → 'https://example.com/search?q=hello%20world'

Key difference: encodeURIComponent encodes everything including /, ?, & — use for parameter values. encodeURI preserves structural characters — use when encoding a complete URL.

Python:

from urllib.parse import quote, quote_plus, urlencode

# Encode a path segment (preserves /)
quote('/path/to/resource')  # → '/path/to/resource'

# Encode a query parameter value
quote('hello world & more')  # → 'hello%20world%20%26%20more'

# HTML form encoding (spaces as +)
quote_plus('hello world')  # → 'hello+world'

# Build a query string from a dict
urlencode({'q': 'hello world', 'page': 1})
# → 'q=hello+world&page=1'  (uses form encoding by default)

# For RFC 3986 encoding in urlencode:
urlencode({'q': 'hello world'}, quote_via=quote)
# → 'q=hello%20world'

PHP:

// Encode a query parameter value (RFC 3986)
rawurlencode('hello world & more');
// → 'hello%20world%20%26%20more'

// Build a query string
http_build_query(['q' => 'hello world', 'page' => 1]);
// → 'q=hello+world&page=1'  (uses form encoding)

Decoding URLs

JavaScript:

decodeURIComponent('hello%20world%20%26%20more');
// → 'hello world & more'

decodeURI('https://example.com/search?q=hello%20world');
// → 'https://example.com/search?q=hello world'

Python:

from urllib.parse import unquote, unquote_plus

unquote('hello%20world%20%26%20more')
# → 'hello world & more'

unquote_plus('hello+world')
# → 'hello world'

Common Mistakes

Double encoding: If you encode a URL and then encode it again, %20 becomes %2520 (% gets encoded to %25). Always encode once, at the point of construction — not at the point of use.

Encoding structural characters: If you encode the ? or & in ?q=hello&page=1, the query string breaks entirely because the parser no longer sees the structural delimiters. Encode only the values, not the URL skeleton.

Not encoding at all: Constructing URLs by string concatenation without encoding is fragile. The moment a user types a &, =, or # in a search field, it breaks the URL.

Forgetting the fragment: The URL fragment (#section) is never sent to the server — it's client-side only. Don't encode it with the rest of the URL if you're building requests.

Quick Reference: When to Encode What

Scenario	Use
Full URL going into a browser	`encodeURI()`
Query parameter value	`encodeURIComponent()`
HTML form submission	Browser handles it
API request parameter	`encodeURIComponent()` / `quote()`
Path segment with special chars	`encodeURIComponent()` / `quote()`

Need to encode or decode a URL right now? SnappyTools URL Encoder/Decoder handles both RFC 3986 and form encoding in your browser — no install needed.

Color Contrast in Web Design: WCAG AA, AAA, and Why It Actually Matters

Snappy Tools — Thu, 21 May 2026 10:03:16 +0000

You've probably seen accessibility issues filed against your app for "insufficient color contrast." Maybe you fixed the obvious cases — dark grey on black, light yellow on white — and called it done.

But contrast is more nuanced than that, and the rules behind it directly affect how usable your UI is for a much larger group of people than most developers realise.

Here's what WCAG contrast levels actually mean, how the math works, and how to use them in practice.

The Core Problem: Relative Luminance

Human eyes don't perceive colour linearly. We're far more sensitive to changes in the darker end of the brightness scale than the bright end.

WCAG defines contrast using relative luminance — a value between 0 (pure black) and 1 (pure white) that accounts for this non-linearity.

For any colour like #3d7c52 (our brand green), the formula:

Converts each RGB channel to a linear value (gamma correction)
Weights them by perceived brightness: 0.2126R + 0.7152G + 0.0722B

The contrast ratio between two colours is then:

contrast = (lighter + 0.05) / (darker + 0.05)

The + 0.05 term prevents division-by-zero and compresses the scale at the extremes. Pure black on pure white gives exactly 21:1 — the maximum possible.

WCAG Levels: AA vs AAA

WCAG 2.1 defines three levels of conformance. Contrast requirements differ for normal text and large text (18pt+ or 14pt+ bold):

Level	Normal Text	Large Text
AA	4.5:1	3:1
AAA	7:1	4.5:1

AA is the minimum legal threshold in many jurisdictions (UK Equality Act, US Section 508, EU EN 301 549). AAA is the ideal for critical content.

There's also a rule for UI components and graphical objects: borders, icons, and interactive element states must meet 3:1 against adjacent colours — a requirement many dashboards fail silently.

Why 4.5:1?

The 4.5:1 threshold was chosen to represent an approximately 20/40 vision impairment — about the level of vision a person with moderate low vision might have, or what an average person in their 70s experiences.

That's a wider audience than most teams acknowledge. About 8% of males have some form of colour vision deficiency. Low-contrast UI also fails in bright sunlight on mobile, on OLED screens with glare, and on low-end displays with poor calibration.

Common Patterns That Fail

Placeholder text

Default browser placeholder text (#767676 on white) hits exactly 4.48:1 — just under AA. It's one of the most commonly failed tests and it's subtle enough to look fine at a glance.

Fix: use color: #595959 for placeholders.

Disabled state text

Many designs use opacity: 0.4 on disabled form fields. A button with green text (#2f855a) at 40% opacity on white will calculate near 1.5:1 — catastrophically low.

Fix: give disabled states an explicit colour that still meets 3:1, even if visually muted.

Hover state changes

Accessibility audits check the default state, but many interactive elements have hover colours that introduce contrast failures. Test hover states explicitly, not just the default.

Coloured text on coloured backgrounds

Dark blue text (#1a365d) on a light blue background (#bee3f8) looks fine — but hits around 3.2:1, failing AA for normal text.

Checking Contrast Without Guessing

The manual formula is tedious. In practice you want a tool you can paste hex codes into and get an instant result.

The Color Contrast Checker at SnappyTools does exactly this — enter two colours, see the contrast ratio, and get an instant AA/AAA pass/fail with a live preview of how the combination actually looks. No signup, no installation.

For larger audits, browser DevTools have a built-in contrast indicator when you inspect text elements. Lighthouse will flag WCAG contrast failures in its accessibility report.

Practical Colour Palettes That Pass

Getting to 4.5:1 against white is easier than it looks if you design for it from the start:

Text: #1a202c (near-black) — 17.2:1 on white
Secondary text: #4a5568 — 7.0:1 on white (AAA)
Muted labels: #718096 — 4.6:1 on white (AA passes, barely)
Links: #2b6cb0 (blue) — 4.7:1 on white
Success green: #276749 — 5.1:1 on white (don't use #38a169 — it's only 2.9:1)
Error red: #c53030 — 5.6:1 on white (#e53e3e fails at 3.1:1)

Notice how the "nice looking" lighter variants almost always fail and the darker alternatives pass. If you build your palette around AAA-compliant base colours and use opacity only for non-text decoration, you'll avoid most contrast bugs before they're filed.

WCAG 3 and APCA

A newer model called APCA (Advanced Perceptual Contrast Algorithm) is being developed for WCAG 3. It's more perceptually accurate — particularly for light text on dark backgrounds, where the 4.5:1 ratio historically underestimates the difficulty.

APCA scores aren't ratios — they're "lightness contrast" values. A score of 75 Lc is roughly equivalent to WCAG AA for body text. The model is still in draft, so WCAG 2.1 AA remains the compliance standard for now.

Quick Checklist

Before shipping any UI with colour:

[ ] Body text (16px+): 4.5:1 against background
[ ] Headings (24px+ or 18.7px bold): 3:1
[ ] Placeholder text: 4.5:1 (not the browser default)
[ ] Disabled elements: 3:1 (not just low opacity)
[ ] Hover/focus states: same thresholds as default
[ ] Icons that convey meaning: 3:1 against adjacent colour
[ ] Error/success state text: 4.5:1

Test combinations early. Retrofitting contrast into a finished design is expensive — rethinking your palette is cheap when you're still in Figma.

Colour contrast is one of those accessibility requirements that also makes your UI better for everyone in suboptimal conditions. It's not just about compliance — it's about building something that works.

If you're checking combinations interactively, snappytools.app/color-contrast-checker/ gives you instant ratio feedback with both the visual preview and the WCAG pass/fail.

JWT Tokens Decoded: What's Actually Inside Your Auth Token

Snappy Tools — Wed, 20 May 2026 10:30:37 +0000

You've seen them — long strings of three dot-separated chunks pasted into Slack, debug logs, and API playgrounds everywhere. JWT tokens are the backbone of modern authentication, but most developers treat them as opaque blobs. Let's open one up.

What a JWT actually is

A JWT (JSON Web Token) is three Base64URL-encoded segments joined by dots:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJKYW5lIERvZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcxNjIzMDAwMCwiZXhwIjoxNzE2MjMzNjAwfQ
.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

The three parts are: header, payload, signature.

The header

Decode the first segment with atob() (or any Base64 decoder) and you get:

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

alg tells the server which algorithm was used to sign the token. Common values:

HS256 — HMAC-SHA256 (symmetric, shared secret)
RS256 — RSA-SHA256 (asymmetric, public/private key pair)
ES256 — ECDSA-SHA256 (asymmetric, elliptic curve)

none is also technically valid — and historically caused major vulnerabilities when servers accepted it.

The payload (the interesting part)

The payload contains claims — statements about the user and the token itself:

{
  "sub": "user_123",
  "name": "Jane Doe",
  "role": "admin",
  "iat": 1716230000,
  "exp": 1716233600
}

Standard registered claims:

Claim	Name	Meaning
`sub`	Subject	Who the token is about (usually a user ID)
`iss`	Issuer	Who created and signed the token
`aud`	Audience	Who the token is intended for
`exp`	Expiration	Unix timestamp — reject if past this time
`nbf`	Not Before	Token not valid before this timestamp
`iat`	Issued At	When the token was created
`jti`	JWT ID	Unique identifier for the token

Custom claims like role, email, permissions are application-specific and perfectly valid.

Important: the payload is Base64URL-encoded, not encrypted. Anyone with the token can read these claims. Never put passwords, credit card numbers, or other secrets in the payload.

The signature

The signature is computed as:

HMAC-SHA256(
  base64url(header) + "." + base64url(payload),
  secret_key
)

The server uses this to verify the token hasn't been tampered with. If you flip one character in the payload, the signature won't match and the token is rejected.

This is what makes JWTs useful — the server doesn't need a database lookup for every request. It just validates the signature mathematically.

Reading a JWT without a library

In JavaScript:

function decodeJwt(token) {
  const [header, payload] = token.split('.');
  const decode = (str) => JSON.parse(atob(str.replace(/-/g, '+').replace(/_/g, '/')));
  return {
    header: decode(header),
    payload: decode(payload)
  };
}

The - → + and _ → / replacements convert Base64URL back to standard Base64, which atob() accepts.

In Python:

import base64, json

def decode_jwt(token):
    parts = token.split('.')
    # Pad to multiple of 4
    payload = parts[1] + '==' 
    return json.loads(base64.urlsafe_b64decode(payload))

The expiry trap

exp is a Unix timestamp (seconds since 1970-01-01 UTC). Check it like this:

const { exp } = decodeJwt(token).payload;
const isExpired = Date.now() / 1000 > exp;

A common mistake: trusting an expired token because you forgot to check exp. JWT libraries like jsonwebtoken (Node.js) and PyJWT (Python) check expiry automatically when you call their verify functions — but raw decoding does not.

The algorithm confusion attack

Never accept alg: none on your server. This was a real vulnerability in early JWT libraries — an attacker could strip the signature and set alg to none, and some servers would accept the forged token as valid.

Similarly, if your server uses asymmetric RS256 (public/private key), an attacker might try sending a token with alg: HS256 and sign it using your public key as the HMAC secret. Always specify the expected algorithm explicitly:

jwt.verify(token, publicKey, { algorithms: ['RS256'] });

Quick decode in the browser

If you're debugging an auth issue and need to quickly inspect what claims a token contains, paste it into this JWT decoder — it decodes header and payload client-side with no server upload, highlights expiry status, and labels all standard claims.

Stateless auth and its tradeoffs

The appeal of JWTs for authentication is statelessness — the server encodes everything it needs into the token and signs it, so there's no session lookup on every request. This scales across multiple servers without shared session storage.

The tradeoff: you can't revoke a JWT before it expires without maintaining a blocklist (which reintroduces state). The standard mitigations:

Short expiry (15 minutes) + refresh tokens (longer-lived, stored server-side)
Revocation list for critical events (logout, password change, account ban)
Token rotation — issue a new access token each time a refresh token is used

JWS vs JWE

What you almost always see is JWS — JSON Web Signature. The payload is readable; the signature prevents tampering.

JWE (JSON Web Encryption) encrypts the payload entirely and produces a 5-part token. Use JWE when the JWT itself must carry sensitive data that shouldn't be readable without a key — most auth tokens don't need this.

JWT tokens are simpler than they look once you see the three-part structure. The magic is all in the signature — a tiny cryptographic proof that the claims haven't changed since the server issued the token.

HEX, RGB, HSL, and CMYK: A Developer's Colour Format Reference

Snappy Tools — Wed, 20 May 2026 10:05:09 +0000

Colours in web and print work live in different worlds. Understanding which format to use — and when — saves you from mysterious colour shifts between your design tool and the browser.

HEX: The Web Default

Hex codes like #2f855a encode red, green, and blue as two hexadecimal digits each (00–FF = 0–255). Three pairs, 16 million possible colours.

color: #2f855a;       /* 6-digit hex */
color: #2f855a80;     /* 8-digit hex with alpha (80 = 50% opacity) */
color: #f06;          /* 3-digit shorthand for #ff0066 */

Use it when: Writing CSS by hand, sharing colours with other developers, working with design systems.

Watch out for: 8-digit hex alpha is broadly supported now but wasn't until ~2017. Check your target browsers.

RGB: The Coordinate System

RGB splits colour into red, green, and blue channels, each 0–255 (or 0%–100%). More readable than hex when you're tweaking individual channels.

color: rgb(47, 133, 90);
color: rgb(47 133 90);           /* modern syntax — no commas */
color: rgb(47 133 90 / 50%);    /* modern syntax with alpha */
color: rgba(47, 133, 90, 0.5);  /* legacy rgba() with decimal alpha */

Use it when: You're programmatically adjusting colour (add 20 to the red channel), or you need precise control over individual channels in JavaScript.

Watch out for: rgba() vs rgb() — modern CSS lets you write rgb(r g b / a) and skip rgba() entirely. Both work.

HSL: The Human Format

HSL (Hue, Saturation, Lightness) maps to how humans think about colour. Hue is 0–360 degrees on a colour wheel. Saturation and Lightness are 0%–100%.

color: hsl(145, 48%, 35%);
color: hsl(145 48% 35%);         /* modern syntax */
color: hsl(145 48% 35% / 50%);  /* with alpha */

Use it when: Building dynamic colour systems in code — darkening a button on hover, generating a palette from a brand colour, or making a colour 20% lighter.

/* Make a colour 15% lighter */
function lighten(h, s, l, amount) {
  return `hsl(${h} ${s}% ${Math.min(l + amount, 100)}%)`;
}

Because lightness is a direct knob, HSL is far better than RGB for programmatic colour manipulation.

Watch out for: HSL doesn't model perceived brightness. Two colours at L=50% look very different in brightness to the human eye (yellow vs blue). For perceptually uniform colour, look at OKLCH.

CMYK: For Print

CMYK (Cyan, Magenta, Yellow, Key/Black) is the colour model for print. CSS doesn't support it natively — it's a print and design tool concept.

If you're handing off assets to a printer or working in Illustrator/InDesign, you'll encounter CMYK. The critical thing: RGB ≠ CMYK. Colours that look vivid on screen can become dull in print because printers can't reproduce some sRGB values.

Conversion is lossy — going from RGB to CMYK loses some gamut. Always convert from RGB to CMYK at the end of your design process, not the start.

#2f855a in RGB → C:65% M:0% Y:57% K:48% in CMYK

OKLCH: The Newcomer Worth Knowing

OKLCH (Oklab Lightness Chroma Hue) is now supported in all modern browsers and solves HSL's perceptual brightness problem.

color: oklch(50% 0.15 145);

The lightness value is perceptually uniform — oklch(50% ... ...) actually looks like the halfway point between black and white, regardless of hue. Great for generating accessible colour palettes algorithmically.

Quick Conversion Reference

Format	Best for	Editable in code?
HEX	CSS, sharing, design handoff	Limited
RGB	Programmatic adjustment	Yes
HSL	Dynamic palettes, theming	Yes
CMYK	Print production	N/A
OKLCH	Accessible palettes, CSS	Yes

Converting Between Formats

If you need to convert between HEX, RGB, HSL, and CMYK online, SnappyTools' free colour picker and converter handles all four formats in both directions — plus includes an eyedropper for picking colours from your screen.

The Practical Rules

Write CSS in HEX — readable, universally supported, paste from anywhere
Manipulate in HSL — adjusting lightness or saturation is one number change
Use RGB for canvas/WebGL — those APIs expect 0–255 values
Convert to CMYK only for print — and use a proper tool, not a formula
Watch your alpha — rgba() is legacy; rgb(r g b / a) is modern

Want to convert between HEX, RGB, HSL, and CMYK without a design tool? SnappyTools' colour picker does it in your browser with no signup required.

Why Your JavaScript Is Too Big (And How to Fix It in 2 Minutes)

Snappy Tools — Tue, 19 May 2026 10:05:50 +0000

Every byte of JavaScript your site ships has to be downloaded, parsed, and executed before your page becomes interactive. For many sites, JavaScript is the single biggest performance bottleneck — and most of it is entirely avoidable bloat.

Here's the thing: the JavaScript you write for development and the JavaScript you serve to users should not be the same file.

What is JavaScript minification?

Minification removes everything from your JS that the browser doesn't need:

Whitespace — newlines, tabs, extra spaces
Comments — helpful for developers, invisible to the browser
Long variable names — userAccountBalance becomes a
Redundant syntax — return true; might become return!0

The result is functionally identical code that can be 30–70% smaller.

Example:

Before:

// Calculate the total price with tax
function calculateTotalPrice(basePrice, taxRate) {
    const taxAmount = basePrice * (taxRate / 100);
    const totalPrice = basePrice + taxAmount;
    return totalPrice;
}

After minification:

function calculateTotalPrice(a,t){return a+a*(t/100)}

Same behaviour. 70% smaller.

Why it matters

JavaScript is render-blocking by default. While the browser is parsing your JS, it pauses everything else.

A real-world example: a 200KB unminified script file might minify down to 60KB. That's 140KB less to transfer over a mobile connection — roughly 0.5–1 second faster on a 4G connection.

At Google's Core Web Vitals thresholds, that's the difference between "good" and "needs improvement."

When to minify

Minify for production. Never serve minified files directly to development — you want readable code with source maps for debugging.

Most build tools (webpack, Vite, Rollup, Parcel) handle this automatically with Terser under the hood. But if you're working on a simple project without a build step, you need to minify manually.

How to minify JavaScript without a build tool

For quick jobs — a standalone script, a bookmarklet, a snippet for a client — use an online minifier.

The important thing is to use a modern engine. Many older online tools use UglifyJS, which doesn't handle ES6+ (async/await, arrow functions, optional chaining). Terser is the current standard — it's what webpack uses, handles modern syntax, and produces smaller output than older tools.

→ Try it: SnappyTools CSS Minifier + Beautifier (and a JS minifier is coming soon)

Should you also minify CSS and HTML?

Yes — but the gains are different:

File type	Typical size reduction
JavaScript	30–70%
CSS	20–40%
HTML	10–20%

JS has the highest payoff because minifiers can also mangle variable names — something CSS/HTML don't support.

The "beautify" direction: unminifying code

Minification is reversible. If you receive minified code and need to read it (debugging a third-party library, auditing a script), a JavaScript beautifier will re-indent and format it back to readable code.

This is the reverse of minification: add whitespace, newlines, and consistent indentation so you can actually read it.

A quick checklist

Before you deploy any JavaScript-heavy page:

[ ] Is your main bundle minified?
[ ] Are you serving gzip or Brotli compressed responses? (Your CDN handles this — check.)
[ ] Are you code-splitting? (Only load what the current page needs.)
[ ] Are there any unused libraries? (Run a quick audit with Chrome DevTools Coverage tab.)

Minification is the easiest win. It takes two minutes and requires no architectural changes.

SnappyTools builds free, fast, browser-based tools for developers. No signup, no data uploaded.

Image to Base64: The Complete Guide (with HTML, CSS, and JavaScript examples)

Snappy Tools — Mon, 18 May 2026 10:07:42 +0000

If you've ever needed to embed an image directly into HTML or CSS without a separate file, you've needed Base64 image encoding. This guide covers everything — what it is, when to use it, and how to do it in HTML, CSS, JavaScript, Python, and Node.js.

What is Base64 image encoding?

Base64 encoding converts binary data (like an image file) into a string of ASCII text characters. The result is a long string that looks like iVBORw0KGgoAAAANSUhEUgAA...

When prefixed with a MIME type, it becomes a data URI that browsers can render directly:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

This data URI can be used anywhere a regular image URL would work — in an <img> tag, a CSS background-image, or a JSON field.

When should you use Base64 images?

Use Base64 for:

Small icons and logos (under 5 KB) — eliminates an HTTP request
HTML email templates — many email clients block external image URLs, so Base64 embedding guarantees images display
Single-file offline HTML apps that can't rely on external paths
API payloads that must carry image data as text (e.g. sending a logo in a REST API response)

Avoid Base64 for:

Large images (over 50 KB) — the 33% size overhead adds up fast
Images used across multiple pages — browsers can't cache Base64 inline images separately
Images that change frequently — you'd need to redeploy code to update the image

The 33% size increase explained

Base64 encodes every 3 bytes of binary data into 4 ASCII characters. This means every image you encode becomes approximately 33% larger.

Original	Base64 size
5 KB icon	~6.7 KB
20 KB logo	~26.7 KB
100 KB photo	~133 KB

For small icons, this is acceptable. For large photos, serve them as regular files.

How to use a Base64 image in HTML

The simplest use case — an inline image:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA..." alt="Logo">

The browser renders this exactly like a normal <img> tag. No network request needed.

How to use a Base64 image in CSS

Embed an image as a CSS background:

.icon {
  background-image: url('data:image/png;base64,iVBORw0KGgo...');
  width: 24px;
  height: 24px;
  background-size: contain;
}

This is a common pattern for small UI icons and spinners — keeps your CSS self-contained.

How to encode an image in JavaScript (browser)

The browser's FileReader API handles this natively:

function imageToBase64(file) {
  return new Promise((resolve, reject) => {
    const reader = new FileReader();
    reader.onload = e => resolve(e.target.result); // full data URI
    reader.onerror = reject;
    reader.readAsDataURL(file);
  });
}

// Usage with a file input:
const file = document.getElementById('fileInput').files[0];
const dataUri = await imageToBase64(file);

// Get just the raw Base64 string (strip the prefix):
const rawBase64 = dataUri.split(',')[1];

// Use in an img tag:
document.getElementById('preview').src = dataUri;

How to encode an image in Python

Python's built-in base64 module makes this straightforward:

import base64

with open('image.png', 'rb') as f:
    data = base64.b64encode(f.read()).decode('utf-8')

# Raw Base64 string
print(data)

# Full data URI
uri = f"data:image/png;base64,{data}"

# Ready-to-paste HTML
html = f'<img src="{uri}" alt="image">'

# Ready-to-paste CSS
css = f"background-image: url('{uri}');"

How to encode an image in Node.js

const fs = require('fs');
const path = require('path');

function imageToBase64(filePath) {
  const data = fs.readFileSync(filePath).toString('base64');
  const ext = path.extname(filePath).slice(1).toLowerCase();
  const mimeMap = {
    png: 'image/png',
    jpg: 'image/jpeg',
    jpeg: 'image/jpeg',
    gif: 'image/gif',
    webp: 'image/webp',
    svg: 'image/svg+xml',
  };
  const mime = mimeMap[ext] || 'image/png';
  return `data:${mime};base64,${data}`;
}

const uri = imageToBase64('./logo.png');
console.log(`<img src="${uri}" alt="logo">`);

Privacy note: client-side vs server-side tools

Many online "image to Base64" converters upload your image to their server to process it. This is a privacy concern if the image contains confidential data.

This can be done entirely in the browser using the FileReader API — no upload required. The image is processed locally and never sent anywhere.

If you need a quick online tool for this, SnappyTools Image to Base64 Encoder does this 100% browser-side — drag and drop your image and get HTML, CSS, data URI, or raw Base64 output in one click.

Summary

Format	What it looks like	When to use
Raw Base64	`iVBORw0KGgo...`	API payloads, further processing
Data URI	`data:image/png;base64,...`	Direct use anywhere a URL works
HTML	`<img src="data:...">`	Paste into HTML files
CSS	`background-image: url(...)`	Paste into stylesheets

Base64 image encoding is a simple technique with clear use cases. Keep images small when embedding, and always prefer external files for larger images that need caching.

URL Encoding Explained: Why %20 Means a Space (and When to Use encodeURIComponent)

Snappy Tools — Sun, 17 May 2026 10:09:28 +0000

If you've ever built a URL with user input in it, you've hit this problem: spaces and special characters break everything. A URL like https://example.com/search?q=hello world is invalid — the space has to become %20. That transformation is URL encoding, and understanding when and how to do it correctly saves a lot of debugging time.

What Is URL Encoding?

URLs can only contain a defined set of safe characters: letters (A–Z, a–z), digits (0–9), and a handful of symbols (-, _, ., ~). Everything else — spaces, &, =, #, /, non-ASCII characters — must be encoded.

URL encoding replaces unsafe characters with a percent sign followed by two hex digits representing the character's ASCII (or UTF-8) value. So:

Character	Encoded
space	`%20`
`&`	`%26`
`=`	`%3D`
`#`	`%23`
`/`	`%2F`
`é`	`%C3%A9`

The %C3%A9 for é shows why it's not just ASCII — modern URL encoding uses UTF-8, where non-ASCII characters can span multiple bytes, each byte getting its own %XX escape.

The Two Forms You'll Actually Use

1. `encodeURIComponent()` — Encode a value

This is what you use for query parameter values and path segments. It encodes everything except letters, digits, -, _, ., and ~.

const query = "coffee & donuts";
const url = `https://example.com/search?q=${encodeURIComponent(query)}`;
// → https://example.com/search?q=coffee%20%26%20donuts

Notice that & gets encoded to %26. That matters — an unencoded & in a query value would be parsed as a new parameter separator, breaking your URL.

2. `encodeURI()` — Encode a full URL

This function leaves URL-structural characters (/, :, ?, &, =, #) alone, because it assumes you're encoding an already-formed URL and don't want to break its structure.

const url = "https://example.com/path with spaces/page?key=value";
encodeURI(url);
// → https://example.com/path%20with%20spaces/page?key=value

Rule of thumb: encodeURIComponent for values, encodeURI for whole URLs.

The Decoding Side: `decodeURIComponent()`

When you read query parameters from a URL, they're already encoded. You need to decode them before use:

const params = new URLSearchParams(window.location.search);
const q = params.get("q"); // URLSearchParams decodes automatically

// Manual approach:
const raw = "%48%65%6C%6C%6F"; // "Hello"
console.log(decodeURIComponent(raw)); // → Hello

URLSearchParams handles decoding automatically, which is why it's worth using over manual string splitting.

Common Mistakes

Encoding the whole URL twice

// Wrong — double-encoding the already-encoded URL
fetch(encodeURIComponent("https://api.example.com/data?key=value"));

// Right — only encode the value part
const key = encodeURIComponent("my value with spaces");
fetch(`https://api.example.com/data?key=${key}`);

Double-encoding turns %20 into %2520 (because % → %25). The server decodes once and gets %20 literally, not a space.

Using `+` instead of `%20`

HTML forms encode spaces as + in application/x-www-form-urlencoded bodies. URL encoding uses %20. The two formats are not interchangeable in all contexts:

%20 is always safe in URLs
+ works in query strings on servers that parse application/x-www-form-urlencoded, but not in path segments

When in doubt, use %20 (i.e., use encodeURIComponent).

Forgetting non-ASCII characters

If you're building a URL with user input that might include accented characters, emoji, or any non-Latin script, you must encode it. encodeURIComponent handles this correctly — it UTF-8 encodes the character first, then percent-encodes each byte.

encodeURIComponent("café");   // → "caf%C3%A9"
encodeURIComponent("日本語"); // → "%E6%97%A5%E6%9C%AC%E8%AA%9E"
encodeURIComponent("🚀");     // → "%F0%9F%9A%80"

A Real-World Example: Building a Search URL

Imagine you're building a "Search on Wikipedia" link from user input:

function wikiLink(query) {
  return `https://en.wikipedia.org/wiki/Special:Search?search=${encodeURIComponent(query)}`;
}

wikiLink("C++ programming language");
// → https://en.wikipedia.org/wiki/Special:Search?search=C%2B%2B%20programming%20language

Notice + in C++ becomes %2B. Without encoding, the server would interpret + as a space.

When You Need to Encode/Decode Quickly

For one-off encoding and decoding during development — converting a value, checking what a percent-encoded string says, or generating a URL hash — a browser-based tool is faster than switching to a Node.js REPL. I use the URL Encoder/Decoder at SnappyTools for this. Paste in a value, get the encoded form, done. No signup, 100% client-side.

Summary

URL encoding replaces unsafe characters with % + two hex digits
encodeURIComponent() — encode a value (encodes &, =, /, +, etc.)
encodeURI() — encode a complete URL (leaves structural characters intact)
URLSearchParams — the cleanest way to build and parse query strings in modern JavaScript
Non-ASCII characters are UTF-8 encoded first, then percent-encoded byte by byte
Never encode the same string twice — you'll get %2520 instead of %20

Get the encoding right once and you'll never waste an afternoon debugging a mysteriously broken API call again.

JSON Schema Explained: How to Validate Your API Data in 10 Minutes

Snappy Tools — Sat, 16 May 2026 10:02:11 +0000

If your API has ever received {"age": "twenty-three"} when it expected a number, you already know why JSON Schema exists.

JSON Schema lets you describe the exact shape of valid JSON data — types, required fields, string patterns, numeric ranges, and much more — and then validate any JSON document against that description. It's the schema language baked into OpenAPI (Swagger), used by Ajv (the most popular JS validator), and understood by almost every modern API toolchain.

This guide covers the essentials: what JSON Schema is, how to write one, and which keywords you'll use 90% of the time.

What Is JSON Schema?

A JSON Schema is itself a JSON document. It describes what another JSON document must look like to be considered valid.

{
  "type": "object",
  "required": ["name", "email"],
  "properties": {
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "format": "email" }
  }
}

This schema says: "I expect an object with at least name (a non-empty string) and email (a valid email address)." Any JSON that satisfies those rules is valid against this schema.

Draft Versions — Which One Should You Use?

JSON Schema has several published drafts. The one you'll encounter most often in production systems is draft-07:

Used by OpenAPI 3.0 (the Swagger standard)
Supported by Ajv (JavaScript), jsonschema (Python), json-schema-validator (Java)
Introduced if/then/else conditional validation
The most widely deployed version as of 2026

The current specification is draft 2020-12, but draft-07 still dominates tooling. Stick with draft-07 unless you have a specific reason to upgrade.

The Keywords You'll Use Most

`type`

Specifies the JSON type of the value. Valid values: string, number, integer, boolean, null, array, object.

{ "type": "integer" }
{ "type": ["string", "null"] }

An array of types means the value can be any of those types — useful for nullable fields.

`properties` and `required`

properties defines the expected fields in an object and their schemas. required lists which fields must be present.

{
  "type": "object",
  "required": ["id", "name"],
  "properties": {
    "id":   { "type": "integer" },
    "name": { "type": "string" },
    "bio":  { "type": "string" }
  }
}

Here, id and name are required; bio is optional but must be a string if present.

`additionalProperties`

Controls whether an object can have fields not listed in properties.

"additionalProperties": false — reject any unknown fields
"additionalProperties": { "type": "string" } — allow extra fields but only if they're strings

For strict API validation where unknown fields should be rejected, false is the right choice.

`enum` and `const`

enum restricts a value to a fixed set of options. const restricts it to exactly one value.

{ "type": "string", "enum": ["admin", "editor", "viewer"] }
{ "const": "published" }

String Constraints

{
  "type": "string",
  "minLength": 3,
  "maxLength": 50,
  "pattern": "^[a-z0-9_]+$",
  "format": "email"
}

minLength / maxLength — character count bounds
pattern — must match this regular expression
format — semantic type: email, uri, date, date-time, ipv4, hostname

Note: format is technically optional in validators — some enforce it, some treat it as annotation only.

Number Constraints

{
  "type": "number",
  "minimum": 0,
  "maximum": 100,
  "multipleOf": 5
}

For exclusive bounds (i.e., strictly greater than / less than), use exclusiveMinimum and exclusiveMaximum. In draft-07, these accept numeric values directly: "exclusiveMinimum": 0 means > 0, not ≥ 0.

Array Constraints

{
  "type": "array",
  "items": { "type": "string" },
  "minItems": 1,
  "maxItems": 10,
  "uniqueItems": true
}

When items is a single schema, every element in the array must match it. For tuple validation (different schemas per position), set items to an array of schemas.

`allOf`, `anyOf`, `oneOf`

These combine multiple schemas:

allOf — data must be valid against all schemas (logical AND)
anyOf — data must be valid against at least one schema (logical OR)
oneOf — data must be valid against exactly one schema

{
  "oneOf": [
    { "properties": { "type": { "const": "circle" } }, "required": ["radius"] },
    { "properties": { "type": { "const": "rect" } }, "required": ["width", "height"] }
  ]
}

This is the JSON Schema way to write a discriminated union.

`$ref` and `$defs`

Reuse schema definitions instead of duplicating them:

{
  "$defs": {
    "Address": {
      "type": "object",
      "required": ["street", "city"],
      "properties": {
        "street": { "type": "string" },
        "city":   { "type": "string" }
      }
    }
  },
  "type": "object",
  "properties": {
    "billing":  { "$ref": "#/$defs/Address" },
    "shipping": { "$ref": "#/$defs/Address" }
  }
}

$defs (or definitions in older schemas) holds reusable definitions. $ref points to them using a JSON Pointer: #/$defs/TypeName.

`if` / `then` / `else`

Draft-07's conditional validation. If the data matches the if schema, it must also satisfy then. If it doesn't match if, it must satisfy else (if provided).

{
  "if":   { "properties": { "plan": { "const": "paid" } }, "required": ["plan"] },
  "then": { "required": ["paymentMethod"] }
}

This requires paymentMethod only when plan is "paid".

Validate Your Schema Right Now

You can test any of the examples above — paste the schema on the left, paste some JSON on the right, and see clear path-based error messages instantly. No signup, no server upload, 100% in your browser:

👉 JSON Schema Validator — SnappyTools

Error messages show the exact JSON path where validation failed (e.g. $.user.address.zip), which makes debugging far faster than generic "invalid payload" errors.

Validating in Code

JavaScript (Node.js / browser):

npm install ajv ajv-formats

import Ajv from 'ajv';
import addFormats from 'ajv-formats';

const ajv = new Ajv();
addFormats(ajv);

const schema = { /* your schema */ };
const validate = ajv.compile(schema);

if (!validate(data)) {
  console.error(validate.errors);
}

Python:

pip install jsonschema

from jsonschema import validate, ValidationError

try:
    validate(instance=data, schema=schema)
    print("Valid!")
except ValidationError as e:
    print(e.message, list(e.absolute_path))

Both libraries implement draft-07 and use the same schema documents — so schemas you write and test in the browser validator work identically in production.

Key Takeaways

JSON Schema describes the shape and constraints of valid JSON data
Draft-07 is the most widely deployed version — it's what OpenAPI 3.0 uses
Essential keywords: type, properties, required, additionalProperties, enum, $ref, allOf/anyOf/oneOf, if/then/else
Validate immediately in the browser: snappytools.app/json-schema-validator
Use Ajv (JS) or jsonschema (Python) for production validation — same schemas, no rewriting

Built something that produces JSON? Add schema validation before it hits production — it takes 10 minutes to write a basic schema and it will save you hours of debugging.

HTML Minification: What Gets Removed and Why It's Safe

Snappy Tools — Fri, 15 May 2026 10:07:04 +0000

Every byte counts when you are serving HTML to millions of requests. HTML minification is one of the cheapest performance wins in front-end development — but developers are often unsure what it actually does to their code and whether it is safe to apply in production.

This article explains what a minifier removes, what it keeps, and the few edge cases where you need to be careful.

What Minification Removes

A minifier strips content that browsers ignore during parsing. Here is what typically gets removed:

Whitespace between tags. Browsers collapse consecutive whitespace into a single space in most contexts. The newlines and indentation between your tags serve human readers, not the parser.

<!-- Before -->
<div>
  <p>
    Hello
  </p>
</div>

<!-- After -->
<div><p>Hello</p></div>

HTML comments.  is parsed and discarded by the browser. There is no runtime value. Some build tools strip them; a minifier will too.

Optional closing tags. The HTML5 spec defines several tags where the closing tag is implied: </li>, </dt>, </dd>, </p>, </td>, </tr>, and others. Browsers handle missing optional tags correctly — the spec exists precisely to allow this.

Redundant attributes. type="text/javascript" on a <script> tag, type="text/css" on a <style> tag, method="get" on a <form> — these are the defaults. A minifier can safely drop them.

Quoted attribute values that do not require quotes. id="app" can become id=app in many cases where the value contains no spaces or special characters. Not all minifiers do this — it is an optional aggressive mode.

What Minification Keeps

Everything that affects rendering or behaviour is kept:

All tag and attribute names
Attribute values (including class names, hrefs, ids)
Whitespace inside <pre> and <textarea> elements (preserved exactly)
Inline script and style content (passed to a JS/CSS minifier separately, or kept verbatim)
data-* attributes
ARIA attributes
Conditional comments (for IE compatibility, if you still support it)

The One Edge Case: Inline Text Whitespace

The space between inline elements matters in flow content. Consider:

<a href="/">Home</a> <a href="/about">About</a>

If a minifier collapses all inter-element whitespace, those two links render with no gap between them. A well-built minifier preserves a single space between inline elements to avoid this layout shift.

The safe rule: whitespace between block elements (divs, paragraphs, headings) can always be removed. Whitespace between inline elements (anchors, spans, strong) should be collapsed to a single space, not removed entirely.

What Are the Savings?

It depends heavily on your HTML structure. A typical HTML page with moderate indentation (2-space or 4-space) saves 10–20% of raw HTML size. A deeply nested template with lots of whitespace can save 30–40%.

In absolute terms, reducing a 50KB HTML page to 42KB saves 8KB per request. At 100,000 daily page views, that is 800MB less data transferred per day — not negligible at scale.

When to Minify

Always in production builds. If you use a build system (webpack, Vite, Parcel), HTML minification should be part of the production build step. The source stays readable; the output goes to users compressed.

Not in development. Minified HTML is hard to debug with DevTools. Keep your development output readable.

For static sites. If you serve pre-built HTML files, run the minifier once at build time. No runtime cost, permanent savings.

For server-rendered output. Most server frameworks can run HTML minification as a middleware that strips the response before it is sent.

Practical: Minify Before You Ship

If you want to quickly check what minification does to a specific HTML file — or beautify an already-minified file back to readable format — the SnappyTools HTML Minifier & Beautifier runs entirely in your browser. Paste your HTML, click Minify, and it shows you the exact bytes saved and the compressed output. No data is uploaded anywhere.

It is also useful in reverse: if you are debugging a minified page from production and need to read it, the Beautify mode re-indents the HTML in seconds.

Summary

Minification removes whitespace, comments, optional closing tags, and redundant attributes
None of these changes affect browser rendering or JavaScript behaviour
Inline element whitespace is the one nuance — a good minifier collapses it to a single space
Savings are typically 10–30%, worthwhile at any traffic scale
Always minify in production builds; always keep source readable in development

Forem: Snappy Tools

JWTs Explained: What's Inside That Token and How to Read It

JWTs Explained: What's Inside That Token and How to Read It

What is a JWT?

Part 1: The Header

Part 2: The Payload

Part 3: The Signature

How to Decode a JWT Instantly

Debugging JWT Issues: Common Problems

JWTs vs Session Tokens

Security Best Practices

Key Takeaway

JSON Schema Explained: Validate Your API Data Before It Breaks Production

What Is JSON Schema?

A Minimal Example

Core JSON Schema Keywords

type

required

properties

String constraints

Number constraints

Array constraints

enum

Nested Objects

Schema Composition: allOf, anyOf, oneOf

Where to Use JSON Schema

Validate JSON Against a Schema Right Now

Quick Reference

Conclusion

JavaScript Minification Explained: How Terser Shrinks Your Code (and Why It Matters)

What JavaScript Minification Actually Does

1. Whitespace and comment removal

2. Name mangling

3. Dead code elimination

4. Constant folding

5. Syntax simplification

ES6+ Support: Why Terser Replaced UglifyJS

Typical Results

When NOT to Mangle Names

How to Minify Without a Build Pipeline

The Flip Side: Beautification

Practical Workflow

Conclusion

URL Encoding Explained: Why Special Characters Break Your URLs (and How to Fix It)

What Is URL Encoding?

Reserved vs Unreserved Characters

The + vs %20 Trap

How to Encode URLs in Code

Decoding URLs

Common Mistakes

Quick Reference: When to Encode What

Color Contrast in Web Design: WCAG AA, AAA, and Why It Actually Matters

The Core Problem: Relative Luminance

WCAG Levels: AA vs AAA

Why 4.5:1?

Common Patterns That Fail

Placeholder text

Disabled state text

Hover state changes

Coloured text on coloured backgrounds

Checking Contrast Without Guessing

Practical Colour Palettes That Pass

WCAG 3 and APCA

Quick Checklist

JWT Tokens Decoded: What's Actually Inside Your Auth Token

What a JWT actually is

The header

The payload (the interesting part)

The signature

Reading a JWT without a library

The expiry trap

The algorithm confusion attack

Quick decode in the browser

Stateless auth and its tradeoffs

JWS vs JWE

HEX, RGB, HSL, and CMYK: A Developer's Colour Format Reference

HEX: The Web Default

RGB: The Coordinate System

HSL: The Human Format

CMYK: For Print

`type`

`required`

`properties`

`enum`

Schema Composition: `allOf`, `anyOf`, `oneOf`

The `+` vs `%20` Trap

1. `encodeURIComponent()` — Encode a value

2. `encodeURI()` — Encode a full URL

The Decoding Side: `decodeURIComponent()`

Using `+` instead of `%20`

`type`

`properties` and `required`

`additionalProperties`

`enum` and `const`

`allOf`, `anyOf`, `oneOf`

`$ref` and `$defs`

`if` / `then` / `else`