DEV Community: Snappy Tools

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

Converting JSON to CSV: How to Flatten Nested Data for Spreadsheets

Snappy Tools — Thu, 14 May 2026 10:06:56 +0000

JSON and CSV both represent tabular data, but they handle structure very differently. JSON can nest objects and arrays indefinitely. CSV is flat — two dimensions, rows and columns. That gap is where most conversion bugs live.

Here is a practical guide to converting JSON to CSV without losing data or your mind.

Why JSON to CSV Conversion Is Harder Than It Looks

A flat JSON array is easy. This converts in seconds:

[
  { "id": 1, "name": "Alice", "role": "admin" },
  { "id": 2, "name": "Bob",   "role": "editor" }
]

id,name,role
1,Alice,admin
2,Bob,editor

The problem starts when your real-world JSON looks like this:

[
  {
    "id": 1,
    "name": "Alice",
    "address": {
      "city": "London",
      "zip": "EC1A"
    },
    "tags": ["admin", "billing"]
  }
]

Now you have choices to make. Should address.city become a column? Should tags become a comma-separated string, or multiple columns, or separate rows?

The answer depends on what you are doing with the CSV.

Approach 1: Dot-Notation Flattening

The most common approach for nested objects is to flatten them with dot notation:

id,name,address.city,address.zip,tags
1,Alice,London,EC1A,"admin,billing"

Here is a minimal JavaScript function that does this:

function flattenObject(obj, prefix = '') {
  return Object.entries(obj).reduce((acc, [key, val]) => {
    const fullKey = prefix ? `${prefix}.${key}` : key;
    if (val !== null && typeof val === 'object' && !Array.isArray(val)) {
      Object.assign(acc, flattenObject(val, fullKey));
    } else {
      acc[fullKey] = Array.isArray(val) ? val.join(';') : val;
    }
    return acc;
  }, {});
}

Then convert the array:

function jsonToCSV(data) {
  const flattened = data.map(row => flattenObject(row));
  const headers = [...new Set(flattened.flatMap(Object.keys))];

  const rows = flattened.map(row =>
    headers.map(h => {
      const val = row[h] ?? '';
      // Escape values that contain commas, quotes, or newlines
      const str = String(val);
      if (str.includes(',') || str.includes('"') || str.includes('\n')) {
        return `"${str.replace(/"/g, '""')}"`;
      }
      return str;
    }).join(',')
  );

  return [headers.join(','), ...rows].join('\n');
}

The key part people forget: proper CSV escaping. A value like "Hello, world" contains a comma. Without quotes, it splits into two columns. Without doubling internal quotes, it breaks the parser.

Approach 2: Stringify Mode

Sometimes you do not need to flatten nested data. You just need it in a spreadsheet for a quick review. In that case, stringify the complex values:

function flattenShallow(obj) {
  return Object.fromEntries(
    Object.entries(obj).map(([k, v]) => [
      k,
      typeof v === 'object' && v !== null ? JSON.stringify(v) : v
    ])
  );
}

This keeps columns clean but stores {"city":"London","zip":"EC1A"} as a raw string in the cell. Readable, but you cannot sort or filter by nested properties.

Approach 3: Explode Arrays to Multiple Rows

If you have a one-to-many relationship — one user with multiple orders — you might want each array element as a separate row:

{ "userId": 1, "orders": [{"id": "A1"}, {"id": "A2"}] }

Becomes:

userId,orders.id
1,A1
1,A2

This produces more rows but is often the right shape for database imports.

Handling Edge Cases

Different objects with different keys. Real APIs return inconsistent shapes. Row 1 might have firstName, row 2 might have first_name. Your header extraction needs to union all keys, not just read the first row:

const headers = [...new Set(data.flatMap(Object.keys))];

Null and undefined values. Use ?? '' (nullish coalescing) rather than || '' — a value of 0 or false is falsy but valid and should not be replaced with an empty string.

Unicode and special characters. Emoji, accented characters, and right-to-left text all survive in CSV as long as you save the file as UTF-8. If your downstream tool opens it in Excel, Excel may interpret the encoding wrong. Adding a BOM () at the start of the file fixes this for most Excel users.

Number formats. A zip code like 00123 is a string, not the number 123. If you stringify everything, it survives. If you try to type-detect values, be careful — leading zeros mean the field is a string.

Triggering a File Download

Once you have the CSV string, downloading it from the browser is three lines:

function downloadCSV(csvString, filename = 'export.csv') {
  const blob = new Blob([csvString], { type: 'text/csv;charset=utf-8;' });
  const url = URL.createObjectURL(blob);
  const a = document.createElement('a');
  a.href = url;
  a.download = filename;
  a.click();
  URL.revokeObjectURL(url);
}

No libraries needed. Works in every modern browser.

When to Use a Library

For production use with complex data, consider Papa Parse — it handles all edge cases and is the standard CSV library for JavaScript.

For quick one-off conversions — pasting an API response and getting a CSV for a spreadsheet — you do not need a library at all.

The SnappyTools JSON to CSV Converter handles nested objects with dot-notation flattening, stringify mode for complex values, live CSV preview, and file download. It runs entirely in your browser with nothing uploaded.

Summary

Flat JSON arrays: trivial to convert
Nested objects: flatten with dot notation or stringify
Arrays of values: join with separator or explode to rows
Always escape commas, quotes, and newlines in cell values
Union all keys across all rows, not just the first row
For browser downloads, use Blob + URL.createObjectURL — no dependencies needed

JSON Schema: How to Validate API Responses Before They Break Your App

Snappy Tools — Wed, 13 May 2026 10:06:11 +0000

If you've ever shipped a bug because an API returned null where you expected a string, you've already experienced the problem JSON Schema solves.

JSON Schema is a vocabulary that lets you describe the structure of your JSON data and validate it automatically. It's been around since 2009 and is now a draft standard under the IETF. If you work with APIs, configs, or any structured JSON, it's worth knowing.

What JSON Schema actually does

A JSON Schema is itself a JSON document that describes what valid JSON looks like. Here's a minimal example:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 }
  }
}

This schema says: the JSON must be an object with id (integer) and email (string, email format) as required fields. age is optional but, if present, must be a non-negative integer under 150.

Run any JSON against this schema and you get a pass/fail result with specific error messages.

The core keywords you need to know

Type keywords: "type": "string", "type": "integer", "type": "number", "type": "boolean", "type": "array", "type": "object", "type": "null". You can allow multiple types with an array: "type": ["string", "null"].

String constraints: minLength, maxLength, pattern (regex). For example: "pattern": "^[a-z]{2,3}$" would match a 2–3 character lowercase language code.

Number constraints: minimum, maximum, exclusiveMinimum, exclusiveMaximum, multipleOf.

Array constraints: items (schema for each element), minItems, maxItems, uniqueItems. With uniqueItems: true, duplicate entries fail validation.

Object constraints: properties (per-key schemas), required (list of required keys), additionalProperties (set to false to ban keys not listed in properties).

Combining schemas: allOf, anyOf, oneOf, not. These let you compose complex validation rules from simpler ones.

A real-world example

Say you're calling a payment API that returns transaction objects. You want to catch bad responses before they reach your business logic:

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "required": ["transaction_id", "amount", "currency", "status"],
  "properties": {
    "transaction_id": { "type": "string", "minLength": 1 },
    "amount": { "type": "number", "exclusiveMinimum": 0 },
    "currency": { "type": "string", "pattern": "^[A-Z]{3}$" },
    "status": { "type": "string", "enum": ["pending", "completed", "failed", "refunded"] },
    "metadata": { "type": "object" }
  },
  "additionalProperties": false
}

This rejects: zero or negative amounts, currencies that aren't 3-letter ISO codes, statuses outside the defined enum, and any unexpected extra fields.

Where JSON Schema is used

API contract testing — validate responses from external APIs before processing
Configuration files — VS Code uses JSON Schema to provide autocomplete and inline validation for settings.json, launch.json, and many extension configs
Form validation — libraries like Ajv run schema validation client-side
CI pipeline checks — validate generated artifacts before deploying
OpenAPI specs — OpenAPI 3.x uses JSON Schema for request/response body definitions

Draft versions and compatibility

The most widely supported version is draft-07. Draft-04 is still common in older codebases. Newer drafts (2019-09, 2020-12) add features like $defs, unevaluatedProperties, and prefixItems for tuple validation, but library support is patchy.

If you're starting fresh, use draft-07 — you get broad tool and library support with minimal compatibility headaches.

Validating quickly without writing code

If you want to test a schema against some JSON right now without setting up a project, you can use a browser-based validator. I built one at SnappyTools JSON Formatter for formatting and validating JSON structure — paste your JSON, see errors highlighted instantly, all client-side with no data sent anywhere.

For schema-specific validation (pairing a schema with an instance and seeing which keywords fail), tools like jsonschema.dev and jsonschemavalidator.net are useful references.

The quick takeaway

JSON Schema is the most practical way to add a validation layer between your app and untrusted JSON data. You don't need a library for simple cases — just knowing the keywords lets you write schemas by hand and reason about what JSON your code will accept.

Start with type, required, and properties. Add minimum/maximum for numbers, pattern for strings, and enum for fixed value sets. That covers 80% of real-world validation needs.

UUID v4 vs UUID v7: Which One Should You Use?

Snappy Tools — Tue, 12 May 2026 10:14:34 +0000

If you've worked with UUIDs, you've almost certainly used UUID v4 — the random, hexadecimal string that looks like 550e8400-e29b-41d4-a716-446655440000. It's everywhere: database primary keys, API identifiers, session tokens.

But there's a newer format gaining traction: UUID v7. It solves a real problem with v4 that trips up developers at scale.

Here's what you need to know.

Quick refresher: What is a UUID?

A UUID (Universally Unique Identifier) is a 128-bit value used to identify something without a central authority. The format is always the same — 32 hexadecimal characters in 5 groups separated by hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx.

The M position indicates the version. The N position indicates the variant.

UUID v4 — The random one

UUID v4 uses 122 bits of cryptographically random data. The remaining 6 bits encode the version (4) and variant (RFC 4122).

f47ac10b-58cc-4372-a567-0e02b2c3d479
              ^                        (version 4 here)

Strengths:

Simple — just generate 122 random bits
Extremely low collision probability (2¹²² possible values)
No information leakage — nothing encodes when or where it was generated
Widely supported across every language and database

Weakness: they don't sort.

This sounds minor but causes real pain in databases. When you insert UUID v4 as a primary key, each new row lands at a random position in the B-tree index. This causes index fragmentation — the database constantly has to reorganise pages. At scale (millions of rows), this degrades write performance and increases storage overhead.

UUID v7 — The time-ordered one

UUID v7 was standardised in RFC 9562 (2024). The first 48 bits are a Unix timestamp in milliseconds, followed by 12 bits of sequence counter, then 62 bits of random data.

018f8e5b-b3c0-7c62-a98b-c8df7cdcbfe0
^^^^^^^^^^^^^^^^^                     (millisecond timestamp here)
                   ^                  (version 7)

Because the timestamp comes first, UUID v7 values are lexicographically sortable by creation time. New rows always append to the end of the index. No fragmentation.

Strengths:

Monotonically increasing — database indexes stay compact
Embeds creation time — useful for debugging ("when was this record created?")
Still globally unique — 62 bits of randomness per millisecond
Compatible with systems expecting UUID format (same structure, just structured differently)

Weakness:

Exposes approximate creation time — a privacy concern if IDs are public
Requires a clock-aware generator — not just random.bytes(16)

Which should you use?

Use v4 when:

Privacy matters — the ID must not reveal creation time
You don't control the database schema (third-party systems, legacy DBs)
You're generating IDs in a context where order genuinely doesn't matter (session tokens, short-lived nonces)

Use v7 when:

The ID is a database primary key — especially with B-tree indexes (PostgreSQL, MySQL, SQLite)
You need sortable IDs without a separate created_at column
You're building event logs, audit trails, or append-heavy workloads
You want timestamp debugging without adding a separate column

Rule of thumb: If you're in control of the schema and the data grows over time, v7 is the better default for primary keys. For everything else, v4 is fine.

Database benchmark reality

Here's the practical difference. In PostgreSQL, if you insert 10 million rows using UUID v4 as the primary key:

Index pages are scattered across disk (random writes)
Vacuum and autovacuum run more frequently
Write-heavy workloads see 20–40% slower inserts compared to sequential IDs

With UUID v7, inserts are nearly as efficient as BIGSERIAL auto-increment, while still being globally unique and not requiring a central counter.

What about UUID v1?

UUID v1 also embeds a timestamp, but it has a critical flaw: it includes the MAC address of the generating machine. That's a privacy and security problem. UUID v7 solves this by using random bits instead of the MAC address for the non-timestamp portion.

UUID v1 is largely obsolete. Don't use it for new work.

What about ULID?

ULID (Universally Unique Lexicographically Sortable Identifier) predates UUID v7 and solves the same problem — sortable, time-ordered IDs. The difference is format: ULIDs use Crockford's Base32 encoding, so they're 26 characters instead of 36. They look like 01ARZ3NDEKTSV4RRFFQ69G5FAV.

If your team is already using ULIDs, stick with them. If you're starting fresh and want standard UUID format (widely supported by ORMs, databases, and tools), UUID v7 is the better choice now that it's RFC-standardised.

Generating UUIDs

Need to generate a UUID v4 for a project or test?

→ Free UUID Generator — snappytools.app generates UUID v4 values in bulk, right in your browser with zero setup.

For UUID v7 in code:

# Python — using the uuid7 package
pip install uuid7
import uuid7
print(uuid7.uuid7())

// Node.js — using uuid package (v9+)
import { v7 as uuidv7 } from 'uuid';
console.log(uuidv7());

-- PostgreSQL 17+ has native UUID v7 support
SELECT gen_random_uuid(); -- still v4
-- For v7: use pgcrypto or uuid-ossp extension, or generate in application layer

Summary

	UUID v4	UUID v7
Sortable	✗	✓
Reveals creation time	✗	✓ (approx)
DB index performance	Moderate	Excellent
Privacy-safe	✓	✗ (exposes timestamp)
RFC standardised	✓ (4122)	✓ (9562, 2024)
Widely supported	✓	Growing

UUID v4 is safe and simple. UUID v7 is better for database primary keys. Now you know the difference.

CSS Color Contrast: The WCAG Rules Every Developer Should Know

Snappy Tools — Mon, 11 May 2026 10:08:09 +0000

Color contrast is one of the most commonly overlooked accessibility requirements in web development — and one of the easiest to fail accidentally. You pick a beautiful grey text on a white background, it looks fine on your calibrated monitor, and then someone with low vision or a washed-out phone screen can't read it at all.

This post covers how contrast ratios work, what WCAG requires, and how to check your colors before they ship.

What Is a Contrast Ratio?

The contrast ratio between two colors is a number from 1:1 (no contrast — same color) to 21:1 (maximum contrast — black on white). It is calculated from the relative luminance of each color, which is a perceptual measure of how bright a color appears to the human eye.

The formula is:

contrast ratio = (L1 + 0.05) / (L2 + 0.05)

where L1 is the luminance of the lighter color and L2 is the luminance of the darker one. Luminance itself is computed from the RGB values after gamma-correcting them (which is why the math is not as simple as just comparing hex codes).

Fortunately, you do not need to calculate this by hand. SnappyTools has a free Color Contrast Checker that computes the ratio instantly and shows you exactly which WCAG levels you pass.

WCAG 2.1 Requirements

The Web Content Accessibility Guidelines define three conformance levels — A, AA, and AAA — and contrast requirements that differ by text size:

Element	AA minimum	AAA enhanced
Normal text (< 18pt or < 14pt bold)	4.5:1	7:1
Large text (≥ 18pt or ≥ 14pt bold)	3:1	4.5:1
UI components and graphics	3:1	—

Level AA is the legal baseline in most jurisdictions (it's what the ADA, EN 301 549, and WCAG 2.1 compliance frameworks reference). Level AAA is aspirational — aim for it on body text where possible.

Common Failures (And How to Spot Them)

Light grey on white

/* Fails AA — ratio ~4.1:1 */
color: #767676;
background: #ffffff;

The classic mistake. #767676 on white is almost exactly at the AA threshold and fails it narrowly. Use #595959 or darker for reliable compliance.

Brand colors with white text

Bright brand colors frequently fail:

#FF6B6B (coral) on white: ~3.0:1 — fails AA for normal text
#FFD700 (gold) on white: ~1.7:1 — fails everything

If your brand color fails contrast on white, either darken the shade for UI text or use dark text on the brand color instead.

Placeholder text

CSS ::placeholder styling inherits from the input but is typically rendered at reduced opacity. The effective contrast of opacity: 0.5 on a #555 placeholder over white is much lower than #555 measured directly. Check your placeholder styling explicitly.

Link underline color

When text-decoration-color is set separately from color, both need adequate contrast. A common pattern that fails: grey underline color on a white background used to subtly de-emphasise links.

Checking Contrast in Your Workflow

There are three points where it's worth checking:

1. During design — before a pixel is written to CSS. Design tools like Figma have contrast plugins (Stark, Contrast) that flag issues while you're still moving colors around.

2. During development — when you translate the design to code. Use a browser-based tool so you can quickly iterate on hex values. The Color Contrast Checker at SnappyTools lets you enter hex codes or use a color picker and shows the ratio and pass/fail for all WCAG levels at once.

3. During audit — before shipping. Chrome DevTools has a contrast ratio indicator in the color picker (accessible when inspecting an element). axe DevTools and Lighthouse both flag contrast failures automatically.

Quick Reference: Ratios That Always Pass

Ratio	Passes
≥ 7:1	AAA normal text, AAA large text
≥ 4.5:1	AA normal text, AAA large text
≥ 3:1	AA large text, AA UI components
< 3:1	Fails everything

Text Over Images and Gradients

WCAG contrast rules assume a flat background. When text sits over an image or gradient, you need to ensure the minimum contrast is met at the worst-case point in the image.

Common solutions:

Text shadow — text-shadow: 0 1px 4px rgba(0,0,0,0.8) works but can look harsh
Semi-transparent scrim — background: linear-gradient(transparent, rgba(0,0,0,0.6)) from the bottom up
Solid background strip — old-fashioned but reliable

None of these are checkable by automated tools — you need a human eye (or a per-pixel luminance calculation) to verify.

One Last Thing: Colour Is Not the Only Signal

WCAG 1.4.1 says you cannot convey information using colour alone. A red/green "error/success" indicator needs a second signal (icon, label, border shape) to be accessible to colour-blind users. This is separate from the contrast ratio — a fully accessible red error state has high contrast and an error icon.

Color contrast takes about 30 seconds to check per color pair. Making it part of your review workflow is one of the highest-ROI accessibility habits you can build.

Use the free Color Contrast Checker — no signup, runs in your browser, shows WCAG AA and AAA results instantly.

CSV and JSON: Converting Between Formats Without Any Libraries

Snappy Tools — Sun, 10 May 2026 10:04:11 +0000

Liquid syntax error: 'raw' tag was never closed

YAML vs JSON: A Practical Guide for Developers

Snappy Tools — Sat, 09 May 2026 10:04:25 +0000

YAML and JSON are both data serialization formats, but they serve different purposes and have very different syntaxes. Choosing the wrong one can make your config files harder to maintain, your APIs harder to integrate, and your tooling chain more fragile.

Here is what you actually need to know.

The Core Difference

JSON (JavaScript Object Notation) was designed for data exchange. It is strict, unambiguous, and machine-readable first. Every string needs quotes. Every key needs quotes. There are no comments. There is no ambiguity about what a value is.

YAML (YAML Ain't Markup Language) was designed for human-readable configuration. It uses indentation instead of braces. Keys do not need quotes for simple strings. Comments are supported. And it can be extremely expressive — almost too expressive.

Same data, both formats:

{
  "server": {
    "host": "localhost",
    "port": 8080,
    "debug": true
  },
  "database": {
    "url": "postgres://localhost/mydb",
    "pool_size": 5
  }
}

server:
  host: localhost
  port: 8080
  debug: true

database:
  url: postgres://localhost/mydb
  pool_size: 5

The YAML version is shorter and easier to read. That is why it became the standard for Kubernetes manifests, GitHub Actions workflows, Docker Compose files, and application config.

When to Use JSON

Use JSON when:

You are building an API. JSON is the lingua franca of web APIs. Every HTTP client in every language can parse it without extra dependencies.
The data will be processed by machines more than humans. JSON's strictness means fewer surprises at parse time.
You need to embed the data in JavaScript. JSON.parse() is built into every browser and Node.js runtime.
Schema validation matters. JSON Schema is widely supported and lets you validate structure before processing.
Performance is a concern. JSON parsers are highly optimized. YAML parsers carry more overhead due to the format's complexity.

When to Use YAML

Use YAML when:

You are writing configuration files. Docker Compose, Kubernetes, Ansible, GitHub Actions, CircleCI, Helm charts — all use YAML because humans edit these files repeatedly.
You need comments. YAML supports # comments. JSON does not. For config files you share with a team, comments are essential documentation.
The file will be read and edited by people. YAML's whitespace-based syntax removes the noise of braces, brackets, and commas.
You are working with multi-line strings. YAML has block scalars (| for literal, > for folded) that make embedding scripts or SQL queries readable.

Where YAML Gets Tricky

YAML's flexibility is also its biggest source of bugs.

The Norway Problem. YAML 1.1 treats no, yes, on, off as booleans. So a country code like NO becomes false. YAML 1.2 fixed this, but many parsers still use 1.1 semantics.

Indentation errors. A single wrong indent level changes the structure of your document entirely, and the error message is often cryptic.

Type coercion. port: 8080 parses as an integer. version: 1.0 might parse as a float. id: 00123 might parse as an octal number (YAML 1.1). These surprises break downstream code expecting strings.

Tabs. YAML forbids tabs for indentation. If your editor inserts a tab instead of spaces, the file fails to parse with a confusing error.

Converting Between YAML and JSON

Sometimes you have one and need the other:

You receive a Kubernetes manifest in YAML and need to send it to an API expecting JSON.
You have a JSON config and need to migrate it to YAML for readability.
You want to validate YAML by converting it to JSON and running JSON Schema against it.

The SnappyTools YAML ↔ JSON Converter handles both directions — paste YAML and get JSON, or paste JSON and get YAML. It runs entirely in the browser with no data uploaded.

Quick Reference

Feature	JSON	YAML
Comments	✗	✓
Human readability	Moderate	High
Strictness	High	Low
Multi-line strings	Escaped `\n` only	Block scalars
Data types	string, number, bool, null, array, object	Same + dates, anchors, aliases
Spec complexity	Simple	Complex
Parser availability	Universal	Language-dependent
Best for	APIs, data exchange	Config files, manifests

The Rule of Thumb

API responses and data exchange: JSON. Config files and manifests: YAML.

If a human will edit the file more than once, YAML wins on ergonomics. If a machine will parse it and human edits are rare, JSON wins on safety and performance.

One more thing: if you are writing YAML configuration and it is getting complicated, consider whether the complexity belongs in code rather than config. YAML can represent deeply nested structures, but it does not mean it should.

Need to convert between YAML and JSON right now? Try the free YAML ↔ JSON Converter — paste either format and get the other instantly, no signup required.

Hashing vs Encryption vs Encoding: What Every Developer Should Know

Snappy Tools — Fri, 08 May 2026 10:23:33 +0000

Three terms that get mixed up constantly. A developer who confuses them will choose the wrong tool — storing passwords with encryption instead of hashing, or using Base64 where they need AES. This post untangles all three.

The Short Answer

	Reversible?	Requires a key?	Common use
Encoding	Yes	No	Transmission (Base64, URL encoding)
Encryption	Yes	Yes	Securing data (AES, RSA, TLS)
Hashing	No	No	Verification (passwords, checksums)

Encoding: Change the Format, Not the Meaning

Encoding transforms data into a different format so it can travel through a system that only accepts a specific character set. It is purely cosmetic — it changes how the data looks, not what it means.

Base64 is the most common encoding. It takes binary data and represents it using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). Used in:

Embedding images in CSS/HTML as data URIs
HTTP Basic Auth headers (username:password → YWRtaW46c2VjcmV0)
JWT tokens (each section is Base64url-encoded)
Email attachments (MIME encoding)

// Encoding — no key, trivially reversible
btoa("admin:secret"); // "YWRtaW46c2VjcmV0"
atob("YWRtaW46c2VjcmV0"); // "admin:secret"

URL encoding converts characters that aren't safe in URLs (spaces, &, =, etc.) to percent-encoded form: hello world → hello%20world.

Critical point: Encoding provides zero security. Anyone can decode Base64 or URL-encoded strings instantly — there's no secret involved. If you see Base64 in a JWT, the payload is readable to anyone who sees the token.

Encryption: Transform Data So Only Authorised Parties Can Read It

Encryption uses a key to scramble data into ciphertext. Without the correct key, the ciphertext is meaningless. With it, you can reverse the process and get the original data back.

Two broad types:

Symmetric encryption (one key for both directions)

// AES-GCM in the Web Crypto API
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 },
  true,
  ["encrypt", "decrypt"]
);

const plaintext = new TextEncoder().encode("hello");
const iv = crypto.getRandomValues(new Uint8Array(12));

const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv },
  key,
  plaintext
);

const decrypted = await crypto.subtle.decrypt(
  { name: "AES-GCM", iv },
  key,
  ciphertext
);

new TextDecoder().decode(decrypted); // "hello"

AES-256 is the standard for symmetric encryption. Used for: encrypting files, databases, HTTPS session data.

Asymmetric encryption (public key encrypts, private key decrypts)

RSA and elliptic curve (ECDSA/ECDH) are common asymmetric algorithms. Used for: TLS handshakes, email encryption (PGP), code signing.

Key management is the hard part. Encryption security depends entirely on keeping keys secret. Lose the key, lose the data. Leak the key, the "encrypted" data is now public.

Hashing: One-Way Transformation

A hash function takes any input and produces a fixed-length output (the hash or digest). The key property: it cannot be reversed. You cannot get the original data back from a hash alone.

// SHA-256 in Web Crypto API
async function sha256(text) {
  const encoded = new TextEncoder().encode(text);
  const buffer = await crypto.subtle.digest("SHA-256", encoded);
  return [...new Uint8Array(buffer)]
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

await sha256("hello");
// "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"

await sha256("hello");
// "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824"
// Identical inputs always produce identical outputs

await sha256("Hello"); // capitalised
// "185f8db32921bd46d35fa8a7d5c5765f18b3f28a15e4b46d2ec9ef7f4ebbf09b"
// Completely different hash for a tiny input change

Where hashing is used

Password storage: Never store passwords in plain text or encrypted form. Store the hash. When a user logs in, hash their input and compare to the stored hash.

// Use bcrypt, Argon2, or scrypt for passwords (not raw SHA-256!)
// These add "work factor" to slow down brute-force attacks
const bcrypt = require("bcrypt");
const hash = await bcrypt.hash("user_password", 12); // 12 = cost factor
const match = await bcrypt.compare("user_password", hash); // true

File integrity: Hash a file and publish the hash. Users download the file, hash it themselves, and compare. If the hashes match, the file wasn't corrupted or tampered with.

Content-addressed storage: Git commits are SHA-1 hashes of their content. Change one byte → completely different hash → git knows something changed.

Data deduplication: Hash file contents; if you've seen that hash before, you've seen that file before.

Common hash algorithms

Algorithm	Output size	Status
MD5	128 bits (32 hex chars)	Broken — collisions found, do not use for security
SHA-1	160 bits (40 hex chars)	Weak — avoid for new systems
SHA-256	256 bits (64 hex chars)	Secure — standard for general use
SHA-512	512 bits (128 hex chars)	Secure — higher security margin
bcrypt	60 chars (includes salt)	Recommended for passwords
Argon2	Variable	Best current choice for passwords

Why MD5 and SHA-1 are broken: Researchers have found ways to produce two different inputs that generate the same hash (a "collision"). A malicious file can be crafted to have the same MD5 hash as a legitimate file. For checksums and non-security uses (cache keys, content IDs), MD5 is still commonly used. For anything security-related — don't.

The Biggest Mistakes

1. Encoding passwords instead of hashing them

Base64 encoding a password is trivially reversible. SHA-256 without a salt is vulnerable to rainbow table attacks. Use bcrypt, Argon2, or scrypt — they're designed for passwords.

2. Encrypting passwords instead of hashing them

If you encrypt passwords, the encryption key becomes the crown jewel of your security. If the key leaks, all passwords are exposed simultaneously. Hashing means even if your database leaks, each password needs to be cracked individually.

3. Using hashing to hide data that needs to be recoverable

Hashes are one-way. If you need to show a user their original data back, use encryption — not hashing.

4. Checking "is this string Base64?" as a security measure

Base64 is not a security primitive. A string that looks like Base64 may contain anything. Validate what the decoded content is, not the encoding.

Quick Decision Guide

Need to transmit binary data as text? → Base64 encoding

Need to secure data that must be recovered later? → AES encryption

Need to store passwords? → bcrypt or Argon2 (not SHA-256!)

Need to verify file integrity? → SHA-256 hash

Need a fast, non-security hash (cache key, dedup)? → SHA-256 or MD5

To generate SHA-256, SHA-512, MD5, and SHA-1 hashes from any text string — instantly in your browser — the SnappyTools Hash Generator does all four at once with no installation or signup. Useful for checksums, debugging, and learning which algorithm produces which format.

7 Things Most Developers Don't Know About JSON.parse() and JSON.stringify()

Snappy Tools — Fri, 08 May 2026 10:21:55 +0000

JSON.parse() and JSON.stringify() look simple. You call one to get data in, call the other to get it out. But both have second and third arguments that most developers never touch — and those arguments unlock features that would otherwise require custom code.

Here are seven things worth knowing.

1. JSON.stringify() has a `space` argument

Everyone knows the first argument. Most people have no idea about the third:

const data = { name: "Alice", age: 30, tags: ["admin", "editor"] };

// Default — minified
JSON.stringify(data);
// '{"name":"Alice","age":30,"tags":["admin","editor"]}'

// Indented with 2 spaces
JSON.stringify(data, null, 2);
// {
//   "name": "Alice",
//   "age": 30,
//   "tags": [
//     "admin",
//     "editor"
//   ]
// }

// Indented with a tab character
JSON.stringify(data, null, '\t');

The space argument accepts either a number (number of spaces) or a string (used as the indent). This is the only argument you need to produce human-readable JSON for logging, debugging, or config files.

2. JSON.stringify() has a `replacer` argument

The second argument is a replacer — a way to transform or filter data during serialisation. It can be an array (allowlist of keys) or a function (transform each value):

const user = { id: 1, name: "Alice", password: "secret", token: "xyz" };

// Array replacer — only include these keys
JSON.stringify(user, ["id", "name"], 2);
// { "id": 1, "name": "Alice" }

// Function replacer — strip null values
JSON.stringify({ a: 1, b: null, c: 3 }, (key, value) => {
  if (value === null) return undefined; // returning undefined removes the key
  return value;
});
// '{"a":1,"c":3}'

// Function replacer — transform dates to ISO strings
JSON.stringify({ createdAt: new Date() }, (key, value) => {
  if (value instanceof Date) return value.toISOString();
  return value;
});

The function replacer receives every key-value pair, including the root object (key is "" at the root). Return undefined to omit the key.

3. JSON.parse() has a `reviver` argument

The reviver is the parse-time counterpart to replacer:

const json = '{"createdAt":"2024-01-15T10:30:00.000Z","updatedAt":"2024-02-01T08:00:00.000Z"}';

// Without reviver — dates are strings
JSON.parse(json).createdAt;
// "2024-01-15T10:30:00.000Z" (string, not Date)

// With reviver — auto-convert ISO date strings to Date objects
JSON.parse(json, (key, value) => {
  if (typeof value === 'string' && /^\d{4}-\d{2}-\d{2}T/.test(value)) {
    return new Date(value);
  }
  return value;
});
// { createdAt: Date object, updatedAt: Date object }

The reviver runs bottom-up — leaf nodes are processed before their parents. This matters when you're transforming nested structures.

4. JSON.stringify() silently drops certain values

This one surprises a lot of people:

const obj = {
  a: 1,
  b: undefined,          // omitted
  c: function() {},      // omitted
  d: Symbol("x"),        // omitted
  e: NaN,                // becomes null
  f: Infinity,           // becomes null
  g: -Infinity,          // becomes null
};

JSON.stringify(obj);
// '{"a":1,"e":null,"f":null,"g":null}'

undefined, functions, and Symbols are silently dropped from objects. In arrays, they become null:

JSON.stringify([1, undefined, function(){}, 4]);
// '[1,null,null,4]'

NaN and Infinity become null — a detail that trips up people working with mathematical data or price calculations in JavaScript.

5. Circular references throw — but you can handle them

const obj = { name: "foo" };
obj.self = obj; // circular reference

JSON.stringify(obj); // throws TypeError: Converting circular structure to JSON

To handle circular references, use a replacer with a WeakSet:

function safeStringify(obj, space) {
  const seen = new WeakSet();
  return JSON.stringify(obj, (key, value) => {
    if (typeof value === 'object' && value !== null) {
      if (seen.has(value)) return '[Circular]';
      seen.add(value);
    }
    return value;
  }, space);
}

const obj = { name: "foo" };
obj.self = obj;
safeStringify(obj);
// '{"name":"foo","self":"[Circular]"}'

This is useful for logging objects that might have circular references (DOM nodes, some Node.js objects).

6. `toJSON()` lets objects control their own serialisation

If an object has a toJSON() method, JSON.stringify() calls it and serialises the return value instead:

class Money {
  constructor(amount, currency) {
    this.amount = amount;
    this.currency = currency;
  }

  toJSON() {
    return `${this.amount} ${this.currency}`; // serialise as a string
  }
}

const price = new Money(9.99, "USD");
JSON.stringify({ price }); // '{"price":"9.99 USD"}'

Date objects use this mechanism — Date.prototype.toJSON calls toISOString(), which is why dates serialise to ISO strings automatically. You can use the same pattern for Money, BigInt wrappers, custom types — any class where the default object form isn't the right representation.

7. Deeply nested structures and the performance limit

JSON.parse() and JSON.stringify() are synchronous and run on the main thread. For very large payloads (>1 MB), they can cause UI jank in a browser context. A few strategies:

// For large payloads, consider structuredClone() instead of JSON round-trip for deep cloning
const deep = structuredClone(bigObject); // faster, handles more types, no JSON overhead

// For streaming large JSON (Node.js), use a streaming parser like JSONStream
const JSONStream = require('JSONStream');
fs.createReadStream('large.json').pipe(JSONStream.parse('*')).on('data', row => {
  // process one row at a time without loading the whole file
});

// For the browser, consider JSON.parse on a background worker for >5MB files
const worker = new Worker('json-worker.js');
worker.postMessage(largeJsonString);
worker.onmessage = e => console.log(e.data); // parsed object

JavaScript's V8 engine has an effective nesting limit of around 500 levels deep before a stack overflow. In practice, no real-world JSON structure gets close to this, but if you're building a JSON generator, keep this in mind.

Quick Reference

Argument	`JSON.stringify(value, replacer, space)`
`replacer`	Array of keys to include, or function to transform each value
`space`	Number of spaces or string to use for indentation

Argument	`JSON.parse(text, reviver)`
`reviver`	Function to transform each parsed value (runs bottom-up)

If you need to format, validate, or minify JSON without writing any code, the SnappyTools JSON Formatter does it in one click — paste your JSON, get it formatted, validated, and ready to copy. No setup, no signup, runs entirely in your browser.

JavaScript String Methods Every Developer Should Know in 2026

Snappy Tools — Fri, 08 May 2026 10:09:45 +0000

Strings are everywhere in JavaScript — parsing URLs, processing user input, building UI labels, talking to APIs. Yet a lot of developers reach for regex or manual loops when a built-in string method would do the job cleaner and faster.

This guide covers the string methods worth memorising in 2026, grouped by what you're trying to do.

Searching and Testing

`includes()`

'hello world'.includes('world') // true
'hello world'.includes('World') // false — case sensitive

Use this instead of indexOf() !== -1. Cleaner intent, same performance.

`startsWith()` / `endsWith()`

'https://example.com'.startsWith('https') // true
'report.csv'.endsWith('.csv')             // true

// With a position argument
'hello world'.startsWith('world', 6) // true — starts at index 6

Useful for file type checks, URL validation, and protocol detection.

`indexOf()` / `lastIndexOf()`

'banana'.indexOf('a')     // 1
'banana'.lastIndexOf('a') // 5
'banana'.indexOf('x')     // -1 (not found)

Still useful when you need the actual position, not just a boolean.

Extracting Parts

`slice(start, end)`

'hello world'.slice(6)     // 'world'
'hello world'.slice(0, 5)  // 'hello'
'hello world'.slice(-5)    // 'world' — negative counts from end

The go-to for extracting substrings. end is exclusive (not included in result).

`substring(start, end)`

Works like slice but doesn't accept negative indices. Prefer slice in modern code.

`at(index)`

'hello'.at(0)   // 'h'
'hello'.at(-1)  // 'o' — last character
'hello'.at(-2)  // 'l'

Cleaner than str[str.length - 1] for accessing from the end.

Transforming

`toUpperCase()` / `toLowerCase()`

'Hello World'.toUpperCase() // 'HELLO WORLD'
'Hello World'.toLowerCase() // 'hello world'

`trim()` / `trimStart()` / `trimEnd()`

'  hello world  '.trim()      // 'hello world'
'  hello world  '.trimStart() // 'hello world  '
'  hello world  '.trimEnd()   // '  hello world'

Always trim user input before comparison or storage.

`replace()` / `replaceAll()`

'foo bar foo'.replace('foo', 'baz')    // 'baz bar foo' — first match only
'foo bar foo'.replaceAll('foo', 'baz') // 'baz bar baz'

// With regex
'hello WORLD'.replace(/[A-Z]+/g, match => match.toLowerCase()) // 'hello world'

`padStart()` / `padEnd()`

'5'.padStart(3, '0')  // '005' — zero-pad numbers
'hi'.padEnd(10, '.')  // 'hi........'

Common for formatting IDs, timestamps, and table output.

`repeat()`

'ha'.repeat(3)  // 'hahaha'
'-'.repeat(40)  // '----------------------------------------'

Splitting and Joining

`split(separator)`

'a,b,c'.split(',')        // ['a', 'b', 'c']
'hello'.split('')         // ['h', 'e', 'l', 'l', 'o']
'hello'.split('', 3)      // ['h', 'e', 'l'] — limit
'a  b  c'.split(/\s+/)   // ['a', 'b', 'c'] — regex separator

Pair with Array.join() to transform and reassemble:

'hello world'
  .split(' ')
  .map(word => word[0].toUpperCase() + word.slice(1))
  .join(' ')
// 'Hello World' — basic title case

Matching with Regex

`match()` / `matchAll()`

'test 123 foo 456'.match(/\d+/g)     // ['123', '456']
'test 123 foo 456'.match(/\d+/)      // ['123', index: 5, ...]

// matchAll gives full match objects (requires /g flag)
const matches = [...'foo 123 bar 456'.matchAll(/(\w+)\s(\d+)/g)]
matches[0][1] // 'foo', matches[0][2] // '123'

`search(regex)`

'hello world'.search(/world/) // 6 (index of match)
'hello world'.search(/xyz/)   // -1

Like indexOf but accepts regex.

Comparing

`localeCompare()`

['banana', 'Apple', 'cherry'].sort((a, b) => a.localeCompare(b))
// ['Apple', 'banana', 'cherry'] — case-insensitive sort

// Language-aware comparison
'é'.localeCompare('e', 'fr') // correctly handles accented characters

Don't use < or > for string sorting — they compare Unicode code points, not linguistic order.

Template Literals (not a method, but worth including)

const name = 'world'
const greeting = `Hello, ${name}!`  // 'Hello, world!'

// Multiline
const html = `
  <div class="card">
    <h2>${title}</h2>
    <p>${description}</p>
  </div>
`

// Tagged templates (advanced)
const result = sql`SELECT * FROM users WHERE id = ${userId}`

Tagged templates are used in libraries like styled-components and graphql-tag — worth understanding even if you don't write your own.

Quick Reference Table

Method	What it does
`includes(s)`	Returns true if string contains `s`
`startsWith(s)`	Returns true if string starts with `s`
`endsWith(s)`	Returns true if string ends with `s`
`indexOf(s)`	Position of first match, -1 if not found
`slice(start, end)`	Extract substring
`at(i)`	Character at index (supports negative)
`toUpperCase()`	All uppercase
`toLowerCase()`	All lowercase
`trim()`	Remove leading/trailing whitespace
`replace(s, r)`	Replace first match
`replaceAll(s, r)`	Replace all matches
`padStart(n, c)`	Pad to length `n` with char `c`
`split(sep)`	Split into array
`match(rx)`	Find matches
`localeCompare(s)`	Linguistically correct comparison

Practical Example: Normalising User Input

Here's a common real-world task — taking raw user input and normalising it for storage:

function normaliseInput(raw) {
  return raw
    .trim()
    .toLowerCase()
    .replace(/\s+/g, ' ')      // collapse multiple spaces to one
    .replace(/[^a-z0-9 ]/g, '') // remove special characters
}

normaliseInput('  Hello   World!! ') // 'hello world'

And for slug generation (URL-friendly strings):

function toSlug(title) {
  return title
    .toLowerCase()
    .trim()
    .replace(/\s+/g, '-')
    .replace(/[^a-z0-9-]/g, '')
}

toSlug('Hello World: A Guide') // 'hello-world-a-guide'

If you work with text a lot and need to quickly switch between camelCase, snake_case, kebab-case, UPPER_CASE and more, the SnappyTools Case Converter handles all common formats in one click — no setup, runs entirely in your browser.

DEV Community: Snappy Tools

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

What Is URL Encoding?

The Two Forms You'll Actually Use

1. encodeURIComponent() — Encode a value

2. encodeURI() — Encode a full URL

The Decoding Side: decodeURIComponent()

Common Mistakes

Encoding the whole URL twice

Using + instead of %20

Forgetting non-ASCII characters

A Real-World Example: Building a Search URL

When You Need to Encode/Decode Quickly

Summary

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

What Is JSON Schema?

Draft Versions — Which One Should You Use?

The Keywords You'll Use Most

type

properties and required

additionalProperties

enum and const

String Constraints

Number Constraints

Array Constraints

allOf, anyOf, oneOf

$ref and $defs

if / then / else

Validate Your Schema Right Now

Validating in Code

Key Takeaways

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

What Minification Removes

What Minification Keeps

The One Edge Case: Inline Text Whitespace

What Are the Savings?

When to Minify

Practical: Minify Before You Ship

Summary

Converting JSON to CSV: How to Flatten Nested Data for Spreadsheets

Why JSON to CSV Conversion Is Harder Than It Looks

Approach 1: Dot-Notation Flattening

Approach 2: Stringify Mode

Approach 3: Explode Arrays to Multiple Rows

Handling Edge Cases

Triggering a File Download

When to Use a Library

Summary

JSON Schema: How to Validate API Responses Before They Break Your App

What JSON Schema actually does

The core keywords you need to know

A real-world example

Where JSON Schema is used

Draft versions and compatibility

Validating quickly without writing code

The quick takeaway

UUID v4 vs UUID v7: Which One Should You Use?

Quick refresher: What is a UUID?

UUID v4 — The random one

UUID v7 — The time-ordered one

Which should you use?

Database benchmark reality

What about UUID v1?

What about ULID?

Generating UUIDs

Summary

CSS Color Contrast: The WCAG Rules Every Developer Should Know

What Is a Contrast Ratio?

WCAG 2.1 Requirements

Common Failures (And How to Spot Them)

Light grey on white

Brand colors with white text

Placeholder text

Link underline color

Checking Contrast in Your Workflow

Quick Reference: Ratios That Always Pass

Text Over Images and Gradients

One Last Thing: Colour Is Not the Only Signal

CSV and JSON: Converting Between Formats Without Any Libraries

YAML vs JSON: A Practical Guide for Developers

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`

1. JSON.stringify() has a `space` argument

2. JSON.stringify() has a `replacer` argument

3. JSON.parse() has a `reviver` argument

6. `toJSON()` lets objects control their own serialisation

`includes()`

`startsWith()` / `endsWith()`

`indexOf()` / `lastIndexOf()`

`slice(start, end)`

`substring(start, end)`

`at(index)`

`toUpperCase()` / `toLowerCase()`

`trim()` / `trimStart()` / `trimEnd()`

`replace()` / `replaceAll()`

`padStart()` / `padEnd()`

`repeat()`

`split(separator)`

`match()` / `matchAll()`

`search(regex)`

`localeCompare()`