Forem: Snappy Tools

WCAG Color Contrast: Why Your UI Might Be Failing Accessibility Tests

Snappy Tools — Wed, 06 May 2026 10:07:16 +0000

You've probably seen accessibility audits flag contrast ratio failures. Maybe Lighthouse gives your site a poor score, or a design review marks text as "unreadable for low-vision users." But what does a contrast ratio actually measure, and what do the thresholds mean?

Here's the practical explanation — with the math kept simple.

What contrast ratio means

The WCAG contrast ratio compares the relative luminance of two colours: foreground (text) and background. Luminance is a measure of perceived brightness, not just the raw RGB value.

The formula:

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

Where L1 is the lighter of the two luminance values and L2 is the darker. The result is a ratio from 1:1 (no contrast — identical colours) to 21:1 (maximum contrast — pure black on pure white).

Relative luminance for an sRGB colour (r, g, b):

For each channel, first linearise:
  if channel <= 0.04045: linear = channel / 12.92
  else: linear = ((channel + 0.055) / 1.055) ^ 2.4

L = 0.2126 × R_linear + 0.7152 × G_linear + 0.0722 × B_linear

The linearisation step is what trips people up. Raw hex values are not luminance values. #808080 (mid-grey) has a luminance of approximately 0.216, not 0.5 — the human eye perceives brightness nonlinearly.

The WCAG thresholds

WCAG 2.1 defines two conformance levels that affect colour contrast:

Level AA (minimum standard, required for most legal compliance):

Normal text (< 18pt, or < 14pt bold): 4.5:1
Large text (≥ 18pt, or ≥ 14pt bold): 3:1
UI components and graphical objects: 3:1

Level AAA (enhanced accessibility):

Normal text: 7:1
Large text: 4.5:1

These thresholds account for users with moderately low vision who don't use assistive technology. Level AA is the target for most production web applications.

Common failures in practice

Placeholder text on inputs

Browsers default to placeholder text at about 40% opacity. Many designers replicate this with color: #999 on a white background, which gives roughly 2.8:1 — well below AA. Fix: use #767676 (color: #767676) for the minimum AA-compliant grey on white.

Light grey text on white

The industry default "muted" colour — #aaa or #999 — fails AA on white backgrounds. A 4.5:1 compliant grey on #fff is at least #767676. Check your card subtitles, helper text, and disabled states.

Coloured buttons

Blue primary buttons often fail when the text is white. #1a73e8 (Google Blue) gives approximately 3.0:1 with white text — passing for large text only. If your button text is small (< 18pt), you need a darker blue.

Brand colour on background

Green (#2f855a — a popular Tailwind green) on white: ~5.1:1. Passes AA. But on a light grey background (#f5f6fa) it drops to ~4.6:1 — still passing, but close. If you lighten the background to #f0f0f0, it fails.

Status badges and tags

Warning yellow is a frequent offender. #fbbf24 on #fff gives roughly 1.7:1. Use #d97706 (amber-600) for the text colour and a light yellow background instead of the reverse.

The icon-only problem

Decorative icons don't need to meet contrast requirements. But informational icons — icons that convey meaning without accompanying text — do. The threshold is 3:1 against the adjacent background.

If you have an error icon that's #ef4444 on #fff, the contrast is about 4.0:1. Passes for an icon (3:1 threshold). But if the same red is used for small text, it fails (needs 4.5:1). Colour alone shouldn't convey information in any case — pair icons with visible labels where possible.

Testing contrast quickly

The fastest approach is a browser DevTools check: inspect an element, go to colour picker, and look for the WCAG AA/AAA badges (Chrome and Firefox both show these inline now).

For a more systematic check — comparing specific hex values, testing a background/text combination across your design system — a standalone tool is faster. I use snappytools.app/color-contrast-checker for this: paste two hex values (or pick with a colour picker), get the ratio, WCAG AA/AAA badge, and an immediate pass/fail. No signup, runs in the browser.

Fixing failures

If text fails:

Darken the text colour — don't lighten the background
Increase font size (large text threshold is 3:1, not 4.5:1)
Use bold weight for borderline cases (14pt+ bold qualifies as "large text")

If a UI component fails:

Add a visible border or outline (the contrast applies to the boundary of the component)
Darken the icon or indicator

If your brand colour fails:

Use the brand colour as an accent — not as the primary text colour on a light background
Create a darker variant for text contexts

WCAG 3.0 and APCA

WCAG 3.0 will replace the current luminance-based ratio with APCA (Advanced Perceptual Contrast Algorithm), which accounts for text size, font weight, and polarity (light-on-dark vs dark-on-light) more accurately. The current 4.5:1 standard can fail in some edge cases (very light backgrounds with mid-grey text) and pass in others where the visual result is borderline.

APCA isn't required yet — WCAG 2.1 is still the legal baseline. But if you're designing a new system, it's worth testing against both.

The takeaway: contrast ratio failures are usually fixable in minutes once you know which elements to check. The three most common culprits — placeholder text, muted body copy, and primary brand colour buttons — cover 80% of the issues in most UI codebases.

CSV to JSON: How to Convert Tabular Data in Pure JavaScript (No Libraries)

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

CSV is everywhere — spreadsheets, data exports, API responses that somehow still use it. JSON is what your code actually wants. Here's how to convert between them in pure JavaScript, without installing anything.

Why CSV to JSON matters

CSV (comma-separated values) is simple and universal. JSON is structured and directly usable in JavaScript. The conversion problem shows up constantly:

You export user data from a CRM as CSV and need to POST it to an API
You get a data dump from a client as a spreadsheet and need to load it into a database
You're reading a config file that someone wrote as CSV for some reason

The basic approach

A CSV file looks like this:

name,age,city
Alice,30,London
Bob,25,Paris
Carol,35,Berlin

The first row is headers. Every row after that is a record. Converting to JSON means turning each row into an object where the keys are the headers.

function csvToJson(csv) {
  const lines = csv.trim().split('\n');
  const headers = lines[0].split(',');

  return lines.slice(1).map(line => {
    const values = line.split(',');
    return headers.reduce((obj, header, i) => {
      obj[header.trim()] = values[i]?.trim() ?? '';
      return obj;
    }, {});
  });
}

Result:

[
  { "name": "Alice", "age": "30", "city": "London" },
  { "name": "Bob",   "age": "25", "city": "Paris"  },
  { "name": "Carol", "age": "35", "city": "Berlin" }
]

This works for simple cases. But CSV has edge cases that will break this.

The hard part: quoted fields

CSV values can contain commas if the value is wrapped in quotes:

name,address,city
Alice,"123 Main St, Apt 4",London

Split on comma breaks "123 Main St, Apt 4" into two pieces. You need a proper parser:

function parseCSVLine(line) {
  const values = [];
  let current = '';
  let inQuotes = false;

  for (let i = 0; i < line.length; i++) {
    const char = line[i];

    if (char === '"') {
      if (inQuotes && line[i + 1] === '"') {
        // Escaped quote inside quoted field
        current += '"';
        i++;
      } else {
        inQuotes = !inQuotes;
      }
    } else if (char === ',' && !inQuotes) {
      values.push(current.trim());
      current = '';
    } else {
      current += char;
    }
  }

  values.push(current.trim()); // last field
  return values;
}

Now use this instead of line.split(',').

Auto-detecting data types

Right now everything comes out as a string, even numbers. You probably want:

function coerceValue(val) {
  if (val === '' || val === null) return null;
  if (val === 'true')  return true;
  if (val === 'false') return false;
  const num = Number(val);
  if (!isNaN(num) && val !== '') return num;
  return val;
}

Apply this to each value after parsing:

obj[header.trim()] = coerceValue(values[i]?.trim() ?? '');

Now "30" becomes 30, "true" becomes true, and empty cells become null.

Handling different delimiters

Some CSV files use tabs, semicolons, or pipes instead of commas. A simple auto-detector:

function detectDelimiter(firstLine) {
  const counts = {
    ',':  (firstLine.match(/,/g)   || []).length,
    '\t': (firstLine.match(/\t/g)  || []).length,
    ';':  (firstLine.match(/;/g)   || []).length,
    '|':  (firstLine.match(/\|/g)  || []).length,
  };
  return Object.entries(counts).sort((a, b) => b[1] - a[1])[0][0];
}

Reading a CSV file from disk

In the browser, use the FileReader API:

const input = document.querySelector('input[type="file"]');

input.addEventListener('change', () => {
  const file = input.files[0];
  if (!file) return;

  const reader = new FileReader();
  reader.onload = (e) => {
    const csv = e.target.result;
    const json = csvToJson(csv);
    console.log(json);
  };
  reader.readAsText(file);
});

No server involved. No data uploaded. Everything runs in the browser.

Downloading the result

To let users save the JSON output:

function downloadJson(data, filename = 'output.json') {
  const blob = new Blob(
    [JSON.stringify(data, null, 2)],
    { type: 'application/json' }
  );
  const url  = URL.createObjectURL(blob);
  const link = document.createElement('a');
  link.href     = url;
  link.download = filename;
  link.click();
  URL.revokeObjectURL(url);
}

Putting it all together

Here's the full working converter — paste it into an HTML file and open it:

<!DOCTYPE html>
<html>
<head><title>CSV to JSON</title></head>
<body>
  <textarea id="csv" rows="10" cols="60" placeholder="Paste CSV here..."></textarea>
  <br>
  <button onclick="convert()">Convert</button>
  <button onclick="download()">Download JSON</button>
  <pre id="output"></pre>

  <script>
    let result = [];

    function parseCSVLine(line, delimiter) {
      const values = [];
      let current = '';
      let inQuotes = false;

      for (let i = 0; i < line.length; i++) {
        const char = line[i];
        if (char === '"') {
          if (inQuotes && line[i + 1] === '"') { current += '"'; i++; }
          else inQuotes = !inQuotes;
        } else if (char === delimiter && !inQuotes) {
          values.push(current.trim());
          current = '';
        } else {
          current += char;
        }
      }
      values.push(current.trim());
      return values;
    }

    function coerce(val) {
      if (!val || val === '') return null;
      if (val === 'true')  return true;
      if (val === 'false') return false;
      const n = Number(val);
      return isNaN(n) ? val : n;
    }

    function convert() {
      const csv = document.getElementById('csv').value.trim();
      const lines = csv.split('\n').filter(Boolean);
      if (!lines.length) return;

      const delim = [',','\t',';','|']
        .map(d => [d, (lines[0].match(new RegExp('\\' + d, 'g')) || []).length])
        .sort((a,b) => b[1] - a[1])[0][0];

      const headers = parseCSVLine(lines[0], delim);
      result = lines.slice(1).map(line => {
        const vals = parseCSVLine(line, delim);
        return Object.fromEntries(headers.map((h, i) => [h, coerce(vals[i] ?? '')]));
      });

      document.getElementById('output').textContent = JSON.stringify(result, null, 2);
    }

    function download() {
      if (!result.length) return alert('Convert first');
      const blob = new Blob([JSON.stringify(result, null, 2)], {type:'application/json'});
      const a = Object.assign(document.createElement('a'), {
        href: URL.createObjectURL(blob), download: 'output.json'
      });
      a.click();
    }
  </script>
</body>
</html>

Common edge cases to handle

Edge case	What breaks	Fix
Commas in values	`split(',')`	Quoted field parser
Windows line endings (`\r\n`)	Extra `\r` in last field	`.replace(/\r/g, '')` before parsing
BOM character (Excel CSVs)	Corrupted first header	Strip from start
Empty rows	Empty objects in output	Filter: `lines.filter(Boolean)`
Duplicate headers	Overwritten values	Append index suffix
Newlines inside values	Broken row splitting	Multi-line aware parser

When this approach is enough

For CSVs under a few MB, this pure-JS approach handles everything you'll hit in practice. For larger files (10MB+), consider streaming with Web Workers to avoid freezing the UI.

If you want a ready-built tool without writing code, SnappyTools has a CSV to JSON converter that runs entirely in your browser — no upload, no account, no nonsense. It handles quoted fields, auto-detects delimiters, parses numbers and booleans, and lets you download the result.

If this helped you, the JSON to CSV converter on the same site goes the other direction — useful when you need to export API data to a spreadsheet.

JWT Tokens Decoded: What's Actually Inside That eyJ… String

Snappy Tools — Mon, 04 May 2026 10:15:21 +0000

You've seen JWT tokens everywhere — in Authorization: Bearer eyJ... headers, in cookies, in OAuth flows. But do you know what's actually inside one?

This post explains JWT structure from scratch, how to decode them manually, what each claim means, and the mistakes developers make when trusting them.

What Is a JWT?

A JWT (JSON Web Token) is a compact, URL-safe string that represents a set of claims. Claims are facts about a subject — usually a user — such as their ID, email, role, or when their session expires.

A JWT looks like this:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEyMyIsIm5hbWUiOiJBbGljZSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTcwNDA2NzIwMCwiZXhwIjoxNzA0MDcwODAwfQ.SIGNATURE_HERE

It has exactly three parts separated by two dots:

Header — algorithm and token type
Payload — the claims (the actual data)
Signature — verifies the token hasn't been tampered with

Why Three Parts?

Part 1: The Header

The header is a Base64URL-encoded JSON object. Decode it and you get:

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

alg tells the receiver which algorithm was used to sign the token (HS256 = HMAC-SHA256)
typ is always JWT

Part 2: The Payload

This is where the actual data lives. Also Base64URL-encoded JSON:

{
  "sub": "user_123",
  "name": "Alice",
  "role": "admin",
  "iat": 1704067200,
  "exp": 1704070800
}

The sub, iat, and exp fields are registered claims defined in RFC 7519. The name and role fields are custom claims added by the application.

Part 3: The Signature

The signature is computed as:

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

This is what prevents tampering. If anyone changes the payload (say, promoting their role from user to admin), the signature won't match — and a proper server-side validation will reject the token.

Decoding vs. Verifying

Here's the critical distinction developers often get wrong:

Decoding = reading the payload (anyone with the token string can do this)

Verifying = checking the signature (requires the signing key)

The payload is not encrypted. It's just Base64URL-encoded — a reversible transformation, not a security measure. Anyone who holds the token string can read every claim in it.

The signature ensures the payload wasn't modified after it was issued. But decoding is still useful for debugging: to check what claims a token actually contains, what expiry time was set, which user ID is included.

Decoding a JWT Manually

Base64URL decoding is straightforward in JavaScript:

function decodeJWT(token) {
  const [headerB64, payloadB64] = token.split('.');

  function b64urlDecode(str) {
    // Base64URL → Base64
    let s = str.replace(/-/g, '+').replace(/_/g, '/');
    // Add padding
    while (s.length % 4) s += '=';
    // Decode UTF-8 bytes
    const bytes = Uint8Array.from(atob(s), c => c.charCodeAt(0));
    return JSON.parse(new TextDecoder().decode(bytes));
  }

  return {
    header: b64urlDecode(headerB64),
    payload: b64urlDecode(payloadB64),
  };
}

The key steps: replace - with + and _ with / (Base64URL → standard Base64), add = padding, decode with atob(), then JSON-parse.

Or just paste the token into SnappyTools JWT Decoder — it decodes header, payload, and expiry status in one click with no setup.

Standard Claims (RFC 7519)

Claim	Full Name	Meaning
`iss`	Issuer	Who issued the token
`sub`	Subject	Who the token is about (usually user ID)
`aud`	Audience	Who the token is intended for
`exp`	Expiration Time	Unix timestamp — reject after this time
`nbf`	Not Before	Unix timestamp — reject before this time
`iat`	Issued At	When the token was issued
`jti`	JWT ID	Unique ID — used to prevent replay attacks

The timestamps (exp, nbf, iat) are Unix timestamps in seconds — not milliseconds. A common bug is checking exp < Date.now() (which is in milliseconds) instead of exp < Date.now() / 1000.

Common Signing Algorithms

The alg header tells the server how to verify the signature:

Symmetric (shared secret):

HS256, HS384, HS512 — HMAC with SHA hash. The same key signs and verifies. Good for single-service tokens. Keep the key secret from clients.

Asymmetric (public/private key):

RS256, RS384, RS512 — RSA. Sign with the private key, verify with the public key. Good for distributed systems where multiple services verify tokens.
ES256, ES384, ES512 — ECDSA. Same idea, smaller signatures.

⚠️ Never accept alg: none. This means the token has no signature and anyone can forge it. A class of vulnerabilities exists where attackers modify the header to "alg": "none" and strip the signature — if the server doesn't validate the algorithm, it accepts the forged token. Always specify which algorithms you accept.

Mistakes Developers Make

1. Trusting the decoded payload without verifying

// ❌ Wrong: decoding without verifying
const payload = JSON.parse(atob(token.split('.')[1]));
if (payload.role === 'admin') { ... }

If you decode without verifying the signature, an attacker can forge any payload. Always verify server-side.

2. Using JWT for sessions and then logging out

JWTs are stateless — there's no server-side record to delete. If a user logs out, the token is still valid until exp. You need a token denylist (or short expiry + refresh tokens) to handle early revocation.

3. Putting sensitive data in the payload

The payload is readable by anyone. Don't put passwords, PII, or secrets in JWT claims.

4. No expiry

A token without an exp claim is valid forever. Always set an expiry — even a generous one — so stolen tokens eventually become useless.

5. Storing access tokens in localStorage

localStorage is accessible to JavaScript — including injected scripts (XSS). Prefer HTTP-only cookies for access tokens where possible.

Debugging JWTs in Practice

When a JWT-authenticated request fails, the first thing to do is decode the token and check:

Is it expired? Check exp against current time.
Is it for the right audience? Check aud.
Is it from the right issuer? Check iss.
Does it have the right algorithm? Check alg in the header.
Does the payload have the expected claims? Check sub, role, scope, etc.

You can do this manually (decode the Base64URL parts), use your IDE's debugger, or use a browser tool like SnappyTools JWT Decoder — paste the token, see everything decoded instantly, get the expiry countdown, and read all standard claims with human-readable labels.

Summary

A JWT is header.payload.signature — all Base64URL-encoded
The payload is not encrypted — anyone can read it
The signature prevents tampering — but only if you verify it server-side
Standard claims (exp, iat, sub, iss) have defined meanings — use them
Never accept alg: none, always set an expiry, and don't store secrets in the payload

Next time you see an eyJ... token, you'll know exactly what's inside.

localStorage vs sessionStorage vs Cookies: When to Use Each

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

Three browser storage mechanisms, each with different lifetimes, scopes, and appropriate uses. Here's when to reach for each.

Overview

Feature	localStorage	sessionStorage	Cookies
Capacity	~5–10 MB	~5 MB	~4 KB
Expires	Never (until cleared)	Tab/session close	Set explicitly
Sent with requests	No	No	Yes (automatically)
Accessible from JS	Yes	Yes	Yes (unless HttpOnly)
Scope	Domain	Tab + domain	Domain (configurable)

localStorage

Stores data with no expiry. Persists until the user clears it or the site clears it.

// Write
localStorage.setItem('theme', 'dark');
localStorage.setItem('user', JSON.stringify({ id: 1, name: 'Alice' }));

// Read
const theme = localStorage.getItem('theme');  // 'dark'
const user = JSON.parse(localStorage.getItem('user'));

// Delete
localStorage.removeItem('theme');

// Clear all
localStorage.clear();

// Check existence
if (localStorage.getItem('onboarded') === null) {
  // first visit
}

All values are strings. Use JSON.stringify / JSON.parse for objects and arrays.

Use for: user preferences (theme, language, layout), non-sensitive app state, data that should survive browser restarts.

Don't use for: authentication tokens, sensitive data. localStorage is accessible from any JavaScript on the page — an XSS vulnerability can read everything.

sessionStorage

Same API as localStorage, but scoped to the current tab and cleared when the tab closes.

sessionStorage.setItem('cart', JSON.stringify(cartItems));
const cart = JSON.parse(sessionStorage.getItem('cart'));

Each tab gets its own sessionStorage. Opening the same URL in two tabs gives each tab independent storage — data in one tab is not visible in the other.

Use for: form state across multiple steps (wizard forms), tab-specific UI state, temporary data that shouldn't persist across sessions.

Don't use for: data that should survive refreshes (it does survive refreshes, but NOT tab close), data shared across tabs.

Cookies

Cookies are old but have specific advantages: they're automatically sent with every HTTP request to the domain, and can be marked HttpOnly to prevent JavaScript access.

// Set a cookie (JavaScript)
document.cookie = 'visited=true; max-age=86400; path=/';

// Read cookies (awkward — they're all in one string)
document.cookie  // "visited=true; theme=dark; lang=en"

// Parsing requires manual work or a library:
function getCookie(name) {
  return document.cookie.split('; ')
    .find(row => row.startsWith(name + '='))
    ?.split('=')[1];
}

// Delete (set expired)
document.cookie = 'visited=; max-age=0; path=/';

Cookie attributes that matter:

Set-Cookie: token=abc123; 
  HttpOnly;           ← JS cannot read this cookie
  Secure;             ← only sent over HTTPS  
  SameSite=Strict;    ← not sent on cross-site requests
  Max-Age=86400;      ← expires in 24 hours
  Path=/              ← sent for all paths

Use for: session tokens (always set HttpOnly + Secure + SameSite), any data the server needs with each request, cross-subdomain data sharing with Domain=.example.com.

Don't use for: large data (4KB limit), client-side-only preferences (unnecessary server overhead), anything that doesn't need to be sent to the server.

Authentication tokens: the right approach

This is where developers make the most consequential storage decision.

JWTs in localStorage: convenient, but vulnerable to XSS. If any third-party script, browser extension, or injected code can run on your page, it can steal the token.

JWTs in HttpOnly cookies: the server sets the cookie with HttpOnly, JavaScript cannot read it, and XSS attacks can't steal it. The cookie is sent automatically with every request. This is the more secure pattern.

// Server sets the cookie (Node.js / Express example)
res.cookie('token', jwt, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  maxAge: 24 * 60 * 60 * 1000  // 24 hours
});

The tradeoff: HttpOnly cookies require CSRF protection (the SameSite attribute handles most cases). localStorage tokens are easier to implement but have a larger XSS attack surface.

For most applications: HttpOnly cookies for auth tokens, localStorage for non-sensitive preferences.

Storage events

localStorage changes in one tab fire an event in other tabs from the same origin:

// In tab A, tab B will receive this event when tab A calls localStorage.setItem
window.addEventListener('storage', (event) => {
  console.log(event.key);      // 'theme'
  console.log(event.newValue); // 'dark'
  console.log(event.oldValue); // 'light'
});

This doesn't fire in the tab that made the change — only in other tabs. Useful for syncing state across tabs.

Checking storage availability

localStorage may be unavailable in private browsing on some browsers or when storage quota is exceeded:

function storageAvailable(type) {
  try {
    const storage = window[type];
    const x = '__storage_test__';
    storage.setItem(x, x);
    storage.removeItem(x);
    return true;
  } catch {
    return false;
  }
}

if (storageAvailable('localStorage')) {
  localStorage.setItem('setting', 'value');
} else {
  // fall back to a cookie or in-memory variable
}

Quick decision guide

Non-sensitive preferences, survives browser close → localStorage
Temporary state for current tab only → sessionStorage
Auth token, needs to be secure → HttpOnly cookie
Sent to server automatically → Cookie
Data shared across subdomains → Cookie with Domain=.example.com
More than 4KB → localStorage or sessionStorage (not cookies)

The key differences: localStorage outlives sessions and tabs; sessionStorage scopes to the current tab; cookies travel to the server and can be made inaccessible to JavaScript. Reach for the mechanism that matches the data's lifetime and who needs to read it.

YAML for Developers: Syntax, Gotchas, and When to Use It

Snappy Tools — Sat, 02 May 2026 10:46:32 +0000

YAML (YAML Ain't Markup Language) is the configuration format behind Docker Compose, Kubernetes, GitHub Actions, Ansible, and most CI/CD pipelines. It's readable, but it has sharp edges. Here's what you need to know.

Basic syntax

YAML uses indentation (spaces only — never tabs) to represent structure:

name: Alice
age: 30
active: true
score: 9.5
nothing: null

These map directly to JSON types: strings, numbers, booleans, null.

Strings

Strings don't need quotes — unless they contain special characters:

# These are all strings without quotes
name: Alice
message: Hello, world
path: /usr/local/bin

# Use quotes when the value would otherwise be misinterpreted
version: "1.0"           # Without quotes: parsed as float 1.0, not string
flag: "true"             # Without quotes: parsed as boolean true
colon: "key: value"      # Without quotes: YAML parser error
empty: ""                # Explicit empty string

Single quotes (') prevent escape sequences. Double quotes (") allow them:

literal: 'Line\nbreak'    # stored as: Line\nbreak (backslash-n literal)
escaped: "Line\nbreak"    # stored as: Line + newline + break

Multiline strings

# Literal block (|): preserves newlines
description: |
  This is the first line.
  This is the second line.
  Newlines are preserved.

# Folded block (>): newlines become spaces
summary: >
  This is a long description
  that wraps across lines.
  Output is one paragraph.

The | block is useful for scripts, SQL queries, or any content where line breaks matter. The > block is useful for long prose that should be treated as a single string.

Lists

# Block sequence
fruits:
  - apple
  - banana
  - cherry

# Inline sequence
fruits: [apple, banana, cherry]

Objects / mappings

# Block mapping
address:
  street: 123 Main St
  city: London
  postcode: SW1A 1AA

# Inline mapping
address: {street: 123 Main St, city: London}

Nested structures

users:
  - name: Alice
    role: admin
    permissions:
      - read
      - write
      - delete
  - name: Bob
    role: viewer
    permissions:
      - read

YAML vs JSON

YAML is a superset of JSON — every valid JSON document is valid YAML. YAML adds:

Comments (#)
Multiline strings
No quotes required for strings
Anchors and aliases for reuse

To convert between the two formats, the YAML to JSON Converter handles both directions and validates syntax.

The Norway problem and other gotchas

Boolean parsing

Different YAML parsers have different rules for implicit booleans. YAML 1.1 (used by many older parsers) treats these as booleans:

# YAML 1.1 — these are all booleans:
yes, no, on, off, true, false, y, n

country: NO      # parsed as boolean false!
toggle: on       # parsed as boolean true

YAML 1.2 (the current spec) only recognizes true and false as booleans. But many tools (PyYAML, Ruby's Psych) still use YAML 1.1 by default.

Fix: always quote values that look like booleans but aren't:

country: "NO"
toggle: "on"

Number parsing

port: 8080     # integer
ratio: 0.5     # float
hex: 0xFF      # integer 255 (YAML 1.1)
octal: 0755    # integer 493 — dangerous! Looks like a permissions string

Version numbers and semver tags are particularly dangerous:

version: 1.10    # parsed as float 1.1 — not the string "1.10"!
version: "1.10"  # correct: preserved as string

Indentation errors

YAML is whitespace-sensitive. Two spaces per level is conventional, but consistency within a file matters more than the number:

# Wrong: inconsistent indentation
servers:
  - name: web
    port: 80
   - name: db   # Error: this dash is at a different indent level
     port: 5432

# Right
servers:
  - name: web
    port: 80
  - name: db
    port: 5432

Tabs are never valid in YAML for indentation. Most YAML errors are either tabs or inconsistent indent depth.

Anchors and aliases

YAML lets you define a value once and reuse it:

defaults: &defaults
  timeout: 30
  retries: 3

development:
  <<: *defaults      # merge all defaults
  host: localhost

production:
  <<: *defaults      # merge again
  host: prod.example.com
  timeout: 60        # override one value

This is especially useful in Docker Compose for sharing service configuration and in CI/CD pipelines for shared job configuration.

Common use cases

GitHub Actions:

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm test

Docker Compose:

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html

Kubernetes deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  template:
    spec:
      containers:
        - name: app
          image: myapp:latest
          ports:
            - containerPort: 8080

When to use YAML vs JSON

Factor	YAML	JSON
Comments	Yes	No
Human writing	Easier	Verbose
Machine generation	Error-prone	Safer
Browser/JS native	Needs library	Native (`JSON.parse`)
Config files	Yes	Possible
API responses	Avoid	Preferred

Use YAML for files humans edit (CI configs, Kubernetes manifests, application config). Use JSON for data exchange between programs.

YAML's strength is readability for humans writing configuration files. Its weakness is the implicit type coercion — things that look like strings silently become booleans or numbers. When in doubt, quote your strings, especially for version numbers, port numbers, country codes, and any value that overlaps with YAML's boolean keywords.

Unix Timestamps: A Complete Developer Reference

Snappy Tools — Sat, 02 May 2026 10:45:49 +0000

Unix timestamps are everywhere in software — database records, API responses, JWT expiry, log files, file metadata. Here's a complete reference for working with them across languages and environments.

What is a Unix timestamp?

A Unix timestamp is the number of seconds elapsed since the Unix epoch: January 1, 1970, 00:00:00 UTC.

0          → 1970-01-01 00:00:00 UTC
1000000000 → 2001-09-09 01:46:40 UTC
1746144000 → 2025-05-02 00:00:00 UTC

Timestamps store a single integer instead of separate year, month, day, hour, minute, second fields — simpler to store, sort, and compare.

To convert between Unix timestamps and human-readable dates, the Unix Timestamp Converter converts in both directions and handles millisecond timestamps too.

Seconds vs milliseconds

JavaScript (and many other environments) uses milliseconds since the epoch, not seconds:

Date.now()  // 1746144000000 (milliseconds)

APIs vary — some return seconds, some milliseconds. A quick way to tell: timestamps in milliseconds are roughly 1000× larger than those in seconds. In 2025:

Seconds: ~1,746,000,000 (10 digits)
Milliseconds: ~1,746,000,000,000 (13 digits)

When in doubt, check the magnitude.

Getting the current timestamp

// JavaScript
Date.now()                     // milliseconds
Math.floor(Date.now() / 1000)  // seconds

# Python
import time
int(time.time())          # seconds
int(time.time() * 1000)   # milliseconds

// Go
import "time"
time.Now().Unix()          // seconds
time.Now().UnixMilli()     // milliseconds

# Shell
date +%s          # seconds
date +%s%3N       # milliseconds

-- PostgreSQL
EXTRACT(EPOCH FROM NOW())::int   -- seconds

Converting timestamp to date

// JavaScript
const ts = 1746144000;           // seconds
const date = new Date(ts * 1000); // Date constructor takes milliseconds
date.toISOString()               // "2025-05-02T00:00:00.000Z"
date.toLocaleDateString()        // locale-specific format

# Python
from datetime import datetime, timezone

ts = 1746144000
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
dt.isoformat()  # '2025-05-02T00:00:00+00:00'

Common gotchas

Forgetting timezone

Timestamps are always UTC. The same timestamp shows different times in different timezones — correct behavior, but easy to misread.

const ts = 1746144000;
const d = new Date(ts * 1000);

d.toISOString()        // "2025-05-02T00:00:00.000Z" — always UTC
d.toLocaleDateString() // "5/1/2025" if you're in US/Pacific (UTC-7) — 11pm the day before!

Off-by-one in seconds/milliseconds

The most common timestamp bug: passing seconds where milliseconds are expected.

// Wrong: passing seconds to Date constructor
new Date(1746144000)        // 1970-01-21 — the timestamp is tiny in millisecond space

// Right:
new Date(1746144000 * 1000) // 2025-05-02
new Date(1746144000000)     // also 2025-05-02

Integer overflow in 32-bit systems

Unix timestamps stored as 32-bit signed integers overflow on January 19, 2038 at 03:14:07 UTC — the Y2K38 problem. 2³¹ - 1 = 2,147,483,647 seconds.

Modern systems use 64-bit integers, which won't overflow for billions of years. But legacy 32-bit databases and embedded systems still need updating.

Timestamp arithmetic

// Add 7 days
const now = Math.floor(Date.now() / 1000);
const oneWeekLater = now + (7 * 24 * 60 * 60);

// How many days ago?
function daysAgo(ts) {
  return Math.floor((Math.floor(Date.now() / 1000) - ts) / 86400);
}

// Is this timestamp in the past?
function isExpired(ts) {
  return ts < Math.floor(Date.now() / 1000);
}

// JWT expiry check (exp field is Unix seconds)
function isJwtExpired(exp) {
  return exp < Math.floor(Date.now() / 1000);
}

Formatting for display

Use Intl.DateTimeFormat for locale-aware formatting:

const ts = 1746144000;
const d = new Date(ts * 1000);

// Relative time ("3 days ago")
const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });
const diffDays = Math.floor((Date.now() / 1000 - ts) / 86400);
rtf.format(-diffDays, 'day');  // "3 days ago"

// Absolute time with explicit timezone
new Intl.DateTimeFormat('en-US', {
  timeZone: 'America/New_York',
  year: 'numeric', month: 'short', day: 'numeric',
  hour: '2-digit', minute: '2-digit'
}).format(d);  // "May 1, 2025 at 08:00 PM"

Storing timestamps in databases

Use 64-bit integer columns for Unix timestamps:

PostgreSQL: BIGINT or native TIMESTAMPTZ (preferred — stores UTC, converts on read)
MySQL: BIGINT UNSIGNED or DATETIME(3) for millisecond precision
SQLite: INTEGER (64-bit internally)
MongoDB: Date type (stores as UTC milliseconds)

TIMESTAMPTZ in PostgreSQL is generally the right choice for application timestamps — it handles timezone conversion automatically. Use raw BIGINT timestamps only when interoperating with systems that exchange raw numbers.

Unix timestamps are simple in principle — one integer representing a moment in UTC — but the seconds/milliseconds distinction and timezone handling cause most of the practical bugs. Get those two right and timestamp work becomes straightforward.

CSS Color Formats: Hex, RGB, HSL, and When to Use Each

Snappy Tools — Sat, 02 May 2026 10:40:53 +0000

CSS supports more color formats than most developers use. Knowing when to reach for hex vs HSL vs oklch affects readability, maintainability, and how easily you can manipulate colors in code.

Hex

The most widely used format. A 6-digit hexadecimal value representing red, green, and blue channels:

color: #3b82f6;  /* blue */
color: #ff0000;  /* red */
color: #000000;  /* black */
color: #ffffff;  /* white */

Each pair represents a channel from 00 (0) to ff (255). You can also use 3-digit shorthand when each pair is a repeated digit:

color: #fff;   /* same as #ffffff */
color: #000;   /* same as #000000 */
color: #f00;   /* same as #ff0000 */

With alpha (transparency): append two more hex digits (00–ff):

color: #3b82f680;  /* 50% opacity blue */
color: #00000040;  /* 25% opacity black */

When to use hex: copying from design tools (Figma, Sketch export hex), existing codebases that use hex, when brevity matters more than readability.

To convert between hex and other formats, the Color Picker shows all representations simultaneously — paste any format and get the others.

RGB

Explicit red, green, blue channels from 0–255:

color: rgb(59, 130, 246);        /* blue */
color: rgba(59, 130, 246, 0.5);  /* 50% opacity blue */

/* Modern syntax — alpha as optional 4th value */
color: rgb(59 130 246);
color: rgb(59 130 246 / 50%);
color: rgb(59 130 246 / 0.5);

The modern rgb(r g b / alpha) syntax (no commas) is now widely supported and preferred over rgba(). Both work.

When to use RGB: when you need to manipulate individual channels in JavaScript, or when working with color values from an API or sensor data.

// Useful for dynamic colors in JavaScript
const r = 59, g = 130, b = 246;
element.style.color = `rgb(${r} ${g} ${b})`;

HSL

Hue, Saturation, Lightness — the most human-intuitive format:

color: hsl(217, 91%, 60%);        /* blue */
color: hsl(217 91% 60%);          /* same, modern syntax */
color: hsl(217 91% 60% / 0.5);    /* 50% opacity */

Hue: 0–360, the color wheel position (0=red, 120=green, 240=blue)
Saturation: 0% (grey) to 100% (fully saturated)
Lightness: 0% (black) to 100% (white)

Why HSL is better for code:

You can intuitively derive color variations by adjusting a single value:

.button {
  background: hsl(217 91% 60%);
}
.button:hover {
  background: hsl(217 91% 50%);  /* darker — just change lightness */
}
.button:disabled {
  background: hsl(217 20% 70%);  /* desaturated — just change saturation */
}

Try doing that with hex. You can't, at least not without calculating the new hex value.

When to use HSL: when creating color systems, theme variations, or any time you need to programmatically derive related colors. Also excellent with CSS custom properties:

:root {
  --brand-hue: 217;
  --brand-saturation: 91%;
}

.primary   { color: hsl(var(--brand-hue) var(--brand-saturation) 60%); }
.primary-dark  { color: hsl(var(--brand-hue) var(--brand-saturation) 45%); }
.primary-light { color: hsl(var(--brand-hue) var(--brand-saturation) 75%); }

HWB

Hue, Whiteness, Blackness — a newer format (CSS Color Level 4):

color: hwb(217 20% 10%);

Less commonly used but can be more intuitive for mixing colors with white or black.

oklch

The most modern and perceptually accurate format:

color: oklch(65% 0.2 264);  /* blue */

L: lightness 0–1 (or 0%–100%)
C: chroma (saturation), roughly 0–0.4
H: hue angle 0–360

Why oklch is better than HSL: HSL's lightness is not perceptually uniform. hsl(60 100% 50%) (yellow) appears much brighter than hsl(240 100% 50%) (blue) despite both having 50% lightness. oklch uses the OKLab color space which is calibrated to human perception — colors at the same lightness value actually look equally bright.

/* These actually look the same lightness in oklch */
.yellow { color: oklch(80% 0.18 105); }
.blue   { color: oklch(80% 0.18 264); }
.pink   { color: oklch(80% 0.18 350); }

/* In HSL, you'd need to manually adjust each */

Browser support: oklch is supported in all modern browsers (Chrome 111+, Firefox 113+, Safari 15.4+). Not supported in IE.

When to use oklch: new projects targeting modern browsers, design systems requiring perceptual color uniformity, when you want accessible color palettes.

Color accessibility

For text on backgrounds, contrast ratio matters. The WCAG 2.1 standard requires:

4.5:1 for normal text (AA)
3:1 for large text (AA)
7:1 for normal text (AAA)

The Color Contrast Checker calculates the ratio between any two colors and shows WCAG AA/AAA pass/fail — paste hex, RGB, or HSL values directly.

Choosing a format

Format	Use when
hex	Design tool export, existing hex-based codebases, brevity
rgb	JavaScript color manipulation, channel-level math
hsl	Color variations, themes, readable color systems
oklch	Perceptually uniform palettes, modern browsers only

One practical approach: use hex for static brand colors, HSL for dynamic variations (hover states, dark mode), oklch when you're building a full design system and need perceptual uniformity.

Consistent usage

Whichever format you choose, be consistent. Mixing hex and HSL across a codebase means every developer has to mentally translate between formats. If using CSS custom properties, define all base colors in one format:

:root {
  /* All colors defined once, in one format */
  --blue-500: hsl(217 91% 60%);
  --blue-600: hsl(217 91% 50%);
  --green-500: hsl(142 71% 45%);
  --red-500: hsl(0 84% 60%);
}

Hex is convenient for copying from design tools. HSL is the most practical for code-driven color systems. oklch is the future for perceptual accuracy. The choice depends on your project's needs — but knowing all three lets you make the call deliberately rather than defaulting to hex out of habit.

Base64 Encoding: What It Is, How It Works, and When to Use It

Snappy Tools — Sat, 02 May 2026 10:40:05 +0000

Base64 is one of those things developers use constantly — in JWTs, data URLs, API authentication — without always understanding what it actually does. Here's a clear explanation.

What Base64 is (and isn't)

Base64 is an encoding scheme, not encryption. It converts binary data into a string of 64 printable ASCII characters: A-Z, a-z, 0-9, +, and /, plus = for padding.

The purpose: safely represent binary data in contexts that only handle text. Email attachments, HTML data URLs, and HTTP headers are all text-based — Base64 lets you embed binary content (images, files) in those contexts without corruption.

If you need to encode or decode Base64 in the browser, the Base64 Encoder/Decoder handles both directions instantly.

How it works

Base64 works in three steps:

Take the binary input as bytes (8 bits each)
Group the bits into 6-bit chunks
Map each 6-bit value (0–63) to one of the 64 characters

Example with "Man":

M = 01001101
a = 01100001
n = 01101110

Combined: 010011010110000101101110

Split into 6-bit groups: 010011 | 010110 | 000101 | 101110
Decimal:                    19  |    22  |     5  |    46
Base64:                      T  |     W  |     F  |     u

Result: "TWFu"

Three bytes of input produce exactly four Base64 characters — a 33% size increase.

Padding

Input doesn't always divide evenly into 3-byte groups. = characters pad the output to a multiple of 4 characters:

1 remaining byte → 2 Base64 chars + ==
2 remaining bytes → 3 Base64 chars + =
3 remaining bytes → 4 Base64 chars (no padding)

Base64 in JavaScript

// Browser — btoa() and atob()
const encoded = btoa('Hello, world!');   // "SGVsbG8sIHdvcmxkIQ=="
const decoded = atob('SGVsbG8sIHdvcmxkIQ==');  // "Hello, world!"

// Node.js — Buffer
const encoded = Buffer.from('Hello, world!').toString('base64');
// "SGVsbG8sIHdvcmxkIQ=="

const decoded = Buffer.from('SGVsbG8sIHdvcmxkIQ==', 'base64').toString('utf8');
// "Hello, world!"

Unicode caveat with btoa()

btoa() only handles characters with code points 0–255. For arbitrary Unicode strings:

// Fails for characters outside Latin-1
btoa('€')  // throws InvalidCharacterError

// Fix: encode as UTF-8 first
function encodeBase64(str) {
  return btoa(encodeURIComponent(str).replace(/%([0-9A-F]{2})/g,
    (_, p1) => String.fromCharCode(parseInt(p1, 16))
  ));
}

// Or in modern environments:
const encoder = new TextEncoder();
const bytes = encoder.encode('Hello, €');
const base64 = btoa(String.fromCharCode(...bytes));

Node.js Buffer handles UTF-8 correctly without this issue.

URL-safe Base64

Standard Base64 uses + and /, which have special meaning in URLs. URL-safe Base64 replaces them:

+ → -
/ → _
= padding is often omitted

This variant is used in JWTs, OAuth tokens, and anywhere Base64 appears in URLs or HTTP headers.

function toBase64Url(base64) {
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

function fromBase64Url(base64url) {
  const padded = base64url.replace(/-/g, '+').replace(/_/g, '/');
  const padding = padded.length % 4 === 0 ? '' : '='.repeat(4 - padded.length % 4);
  return padded + padding;
}

Common uses

Data URLs (embedding images in HTML/CSS)

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

.icon {
  background-image: url('data:image/svg+xml;base64,PHN2ZyB4bWxucy...');
}

This embeds the image directly in the HTML or CSS file — no extra HTTP request. Useful for tiny icons, but avoid for anything larger than ~1KB (base64 adds 33% overhead and can't be cached separately).

HTTP Basic Authentication

const credentials = btoa('username:password');
fetch('/api/data', {
  headers: {
    'Authorization': `Basic ${credentials}`
  }
});

Basic Auth Base64-encodes the username:password string. Note: this is not encryption — it's trivially reversible. Always use HTTPS.

JWT tokens

The header and payload sections of a JWT are Base64Url-encoded JSON:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0In0.abc123
^--- header ---^              ^-payload-^  ^-signature-^

Decoding the header: atob('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') → {"alg":"HS256","typ":"JWT"}

Email attachments (MIME)

Content-Type: application/pdf; name="document.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovVHlwZSAvQ2F0YWxvZwov...

MIME uses Base64 to embed binary attachments in the text-based email format.

Base64 is not encryption

This is worth repeating. Base64 encoding is completely reversible without any key — it's a standard algorithm anyone can reverse. Never use it to protect sensitive data.

Using Base64 to "hide" a password or API key is security theater. An attacker who sees the encoded string can decode it in seconds.

For actual security: use encryption (AES for symmetric, RSA/ECDSA for asymmetric) or hashing (bcrypt/Argon2 for passwords, SHA-256+ for integrity checks).

Size trade-offs

Original: 100 bytes binary
Base64:   136 bytes (33% larger)

Original: 1 MB image
Base64:   1.37 MB

The 33% overhead is predictable: 3 input bytes → 4 output characters. For images and files, this overhead is why external files + HTTP caching is usually better than data URLs beyond small sizes.

Base64 exists to solve a specific problem: safely transmitting binary data through text-only channels. When you see it in JWTs, data URLs, or API credentials, that's what it's doing. It's not compression, not encryption — just a reliable way to represent bytes as printable text.

JavaScript Array Methods: map, filter, reduce, and Everything Else You Need

Snappy Tools — Sat, 02 May 2026 10:39:13 +0000

JavaScript's array methods are one of those topics where the basics are well-known but the full picture saves significant time. Here's a practical reference, from the commonly used to the ones most developers forget exist.

The big three: map, filter, reduce

map — transform each element

map() creates a new array by applying a function to each element:

const prices = [10, 20, 30];
const withTax = prices.map(price => price * 1.2);
// [12, 24, 36]

const users = [{ name: 'Alice', age: 30 }, { name: 'Bob', age: 25 }];
const names = users.map(user => user.name);
// ['Alice', 'Bob']

map() always returns an array of the same length. If you want to transform and potentially skip elements, use filter() + map() chained, or use reduce().

filter — select elements

filter() creates a new array containing only elements where the function returns true:

const numbers = [1, 2, 3, 4, 5, 6];
const evens = numbers.filter(n => n % 2 === 0);
// [2, 4, 6]

const activeUsers = users.filter(user => user.active);

reduce — accumulate into a single value

reduce() is the most general but also most misunderstood. It takes an accumulator and current element, and returns the new accumulator value:

// Sum
const sum = [1, 2, 3, 4, 5].reduce((acc, curr) => acc + curr, 0);
// 15

// Count occurrences
const words = ['apple', 'banana', 'apple', 'cherry', 'banana', 'apple'];
const counts = words.reduce((acc, word) => {
  acc[word] = (acc[word] || 0) + 1;
  return acc;
}, {});
// { apple: 3, banana: 2, cherry: 1 }

// Flatten one level
const nested = [[1, 2], [3, 4], [5, 6]];
const flat = nested.reduce((acc, arr) => [...acc, ...arr], []);
// [1, 2, 3, 4, 5, 6]

The second argument (the 0 or {} above) is the initial accumulator. If you omit it, reduce() uses the first element — which works for numbers but can behave unexpectedly for objects.

Searching: find, findIndex, findLast

const users = [
  { id: 1, name: 'Alice' },
  { id: 2, name: 'Bob' },
  { id: 3, name: 'Charlie' }
];

// First element matching condition
users.find(u => u.id === 2)       // { id: 2, name: 'Bob' }

// Index of first match
users.findIndex(u => u.id === 2)  // 1

// Last element matching condition (ES2023)
users.findLast(u => u.id < 3)     // { id: 2, name: 'Bob' }

// Returns -1 or undefined if not found:
users.find(u => u.id === 99)      // undefined
users.findIndex(u => u.id === 99) // -1

Checking: some, every, includes

const scores = [85, 90, 78, 95, 62];

// Does any element match?
scores.some(s => s >= 90)   // true

// Does every element match?
scores.every(s => s >= 60)  // true
scores.every(s => s >= 80)  // false

// Does the array contain this value?
scores.includes(90)  // true
[1, 2, NaN].includes(NaN)  // true — unlike indexOf

some() returns true as soon as it finds a match. every() returns false as soon as it finds a non-match. Both short-circuit.

Sorting: sort

const fruits = ['banana', 'apple', 'cherry'];
fruits.sort()  // ['apple', 'banana', 'cherry'] — lexicographic sort in place

// Numeric sort (IMPORTANT — the default sort is string-based!)
[10, 9, 2, 21].sort()              // [10, 2, 21, 9] — WRONG for numbers
[10, 9, 2, 21].sort((a, b) => a - b)  // [2, 9, 10, 21] — correct ascending
[10, 9, 2, 21].sort((a, b) => b - a)  // [21, 10, 9, 2] — correct descending

// Sort objects by property
users.sort((a, b) => a.name.localeCompare(b.name));

sort() modifies the original array in place. If you need a sorted copy, spread first: [...array].sort(...).

Flattening: flat, flatMap

// flat() — flatten nested arrays
[[1, 2], [3, 4]].flat()         // [1, 2, 3, 4]
[[1, [2, 3]], [4]].flat()       // [1, [2, 3], 4] — only one level deep
[[1, [2, 3]], [4]].flat(2)      // [1, 2, 3, 4] — two levels deep
[[1, [2, [3]]]].flat(Infinity)  // [1, 2, 3] — all levels

// flatMap() — map then flatten one level
const sentences = ['hello world', 'foo bar'];
sentences.flatMap(s => s.split(' '))  // ['hello', 'world', 'foo', 'bar']
// Equivalent to sentences.map(s => s.split(' ')).flat()

Slice and splice

const arr = [1, 2, 3, 4, 5];

// slice — returns portion without modifying original
arr.slice(1, 3)    // [2, 3] — from index 1 (inclusive) to 3 (exclusive)
arr.slice(-2)      // [4, 5] — last 2 elements
arr.slice()        // [1, 2, 3, 4, 5] — shallow copy

// splice — modifies original, removes and/or inserts
arr.splice(1, 2)   // removes 2 elements starting at index 1, returns [2, 3]
// arr is now [1, 4, 5]

arr.splice(1, 0, 99)  // insert 99 at index 1, remove 0 elements
// arr is now [1, 99, 4, 5]

A helpful mnemonic: slicE = no Effect on original, splicE = Effect on original.

Conversion: Array.from, Array.of, join

// Array.from — create array from iterable or array-like
Array.from('hello')              // ['h', 'e', 'l', 'l', 'o']
Array.from({length: 5}, (_, i) => i)  // [0, 1, 2, 3, 4]
Array.from(new Set([1, 2, 2, 3]))    // [1, 2, 3] — Set to array

// join — array to string
[1, 2, 3].join(', ')   // "1, 2, 3"
[1, 2, 3].join('')     // "123"
[1, 2, 3].join('\n')   // "1\n2\n3"

// toString is shorthand for join(',')
[1, 2, 3].toString()   // "1,2,3"

at() — negative indexing

const arr = [10, 20, 30, 40, 50];
arr.at(0)   // 10
arr.at(-1)  // 50 — last element
arr.at(-2)  // 40 — second to last

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

Structuring complex data transformations

For complex pipelines, chain methods clearly:

const result = users
  .filter(user => user.active)
  .map(user => ({
    id: user.id,
    displayName: `${user.firstName} ${user.lastName}`,
    email: user.email.toLowerCase()
  }))
  .sort((a, b) => a.displayName.localeCompare(b.displayName));

This is easier to read and debug than a single complex reduce(). Reserve reduce() for accumulation (building an object, computing a sum) rather than using it as a general-purpose replacement for the other methods.

Array methods are one of those areas where knowing the full toolbox makes your code noticeably cleaner. find() instead of filter()[0], some() instead of a manual loop with a boolean flag, flatMap() instead of map().flat() — small choices that add up across a codebase.

The CSS Box Model: Margin, Padding, Border, and box-sizing Explained

Snappy Tools — Sat, 02 May 2026 10:36:34 +0000

The CSS box model is one of the first things you learn and one of the concepts you come back to most often. Understanding it properly — especially the difference between box-sizing: content-box and box-sizing: border-box — prevents a class of layout bugs that affect almost every developer at some point.

What is the box model?

Every HTML element is a rectangular box with four layers:

┌─────────────────────────────────────┐
│               MARGIN                 │  ← transparent, clears space around border
│   ┌─────────────────────────────┐   │
│   │            BORDER           │   │  ← the visible edge (if border is set)
│   │  ┌───────────────────────┐  │   │
│   │  │        PADDING        │  │   │  ← transparent, space inside border
│   │  │  ┌─────────────────┐  │  │   │
│   │  │  │     CONTENT     │  │  │   │  ← where text and child elements live
│   │  │  └─────────────────┘  │  │   │
│   │  └───────────────────────┘  │   │
│   └─────────────────────────────┘   │
└─────────────────────────────────────┘

Content: the area where your text, images, or child elements appear
Padding: transparent space between content and border
Border: the visible edge (optional)
Margin: transparent space outside the border, separating this element from others

The content-box problem

By default, width and height in CSS refer to the content area only. Padding and border are added on top of the specified size.

.box {
  width: 300px;
  padding: 20px;
  border: 2px solid black;
}

Actual rendered width: 300 + 20 + 20 + 2 + 2 = 344px

This is box-sizing: content-box, the original CSS behaviour. It's counterintuitive: specifying width: 300px does not mean the box is 300px wide — it means the content area inside the box is 300px.

The border-box solution

box-sizing: border-box changes what width and height include:

.box {
  box-sizing: border-box;
  width: 300px;
  padding: 20px;
  border: 2px solid black;
}

Actual rendered width: 300px — exactly.

With border-box, the padding and border are included in the specified dimensions. The content area shrinks to accommodate them: 300 - 20 - 20 - 2 - 2 = 256px content width.

Most modern CSS approaches apply border-box universally:

*, *::before, *::after {
  box-sizing: border-box;
}

Frameworks like Bootstrap, Tailwind, and Material UI all do this. It's the setting almost every new project should start with.

Margin

Margin is the space outside the border. It's transparent — the background colour of the element doesn't show in the margin area.

/* All sides: 20px */
margin: 20px;

/* Vertical 10px, Horizontal 20px */
margin: 10px 20px;

/* Top, Right, Bottom, Left */
margin: 10px 20px 30px 40px;

/* Individual sides */
margin-top: 10px;
margin-right: 20px;
margin-bottom: 10px;
margin-left: 20px;

/* Auto margins for horizontal centering */
margin: 0 auto;  /* requires a fixed width */

Margin collapsing

Adjacent vertical margins collapse into a single margin equal to the larger of the two:

.a { margin-bottom: 20px; }
.b { margin-top: 30px; }
/* Space between a and b: 30px, not 50px */

Margin collapsing only happens with vertical margins (top and bottom), not horizontal ones. It does not happen in flex containers or grid containers.

Padding

Padding is the space between content and border. Unlike margin, the element's background colour shows in the padding area.

padding: 20px;
padding: 10px 20px;
padding: 10px 20px 30px 40px;
padding-top: 10px;

Click targets: padding increases the clickable area of an element without changing its visible size (when there's no visible border). This is why padding is often used on small icons and links to make them easier to tap on mobile.

Border

border: 1px solid #e2e8f0;
border: 2px dashed red;
border: none;

/* Individual sides */
border-top: 1px solid #ccc;
border-bottom: 2px solid var(--accent);

/* Individual properties */
border-width: 1px;
border-style: solid;  /* solid, dashed, dotted, double, none */
border-color: #ccc;

/* Radius */
border-radius: 8px;
border-radius: 50%;  /* circle (when width = height) */
border-radius: 4px 8px 4px 8px;  /* top-left, top-right, bottom-right, bottom-left */

outline is similar to border but doesn't affect the box model — it draws outside the border without affecting layout or the element's dimensions. Commonly used for focus indicators.

Common layout patterns

Centring a block element:

.container {
  width: 800px;
  max-width: 100%;  /* responsive fallback
  margin: 0 auto;
}

Equal spacing inside a card:

.card {
  padding: 24px;
  border-radius: 8px;
  border: 1px solid #e2e8f0;
}

Separating list items:

.list-item + .list-item {
  margin-top: 8px;  /* space between items, not after the last one */
}
/* Or: */
.list-item:not(:last-child) {
  margin-bottom: 8px;
}

Debugging with DevTools

In Chrome DevTools, click any element and open the Computed tab — you'll see the box model diagram with the actual pixel values for content, padding, border, and margin. Hovering over a CSS property in the Styles tab shows the effect on the element. Clicking the box model diagram also lets you edit values inline.

The box model is one of those fundamentals that's worth revisiting when a layout doesn't behave as expected. Most sizing bugs come down to forgetting whether padding and border are included in width, or to unexpected margin collapse. Apply box-sizing: border-box globally and most sizing surprises disappear.

Markdown Tips for Developers: Beyond the Basics

Snappy Tools — Sat, 02 May 2026 10:35:49 +0000

Most developers know the basics: **bold**, # heading, [link](url). But Markdown has features that even experienced writers overlook. Here are the ones worth knowing.

Fenced code blocks with syntax highlighting

The basic syntax:

```

javascript
const greeting = 'Hello, world!';
console.log(greeting);


```
```

`

The language hint after the opening backticks enables syntax highlighting in GitHub, GitLab, Dev.to, Notion, and most Markdown renderers. Common language identifiers: `javascript`, `typescript`, `python`, `bash`, `sql`, `yaml`, `json`, `css`, `html`, `go`, `rust`.

For terminal output: use `bash` or `shell`. For file paths and commands: use `console` or `text`.

## Task lists (GitHub Flavored Markdown)

```markdown
- [x] Set up the project
- [x] Add authentication
- [ ] Write tests
- [ ] Deploy to staging
```

Renders as interactive checkboxes on GitHub and GitLab. In a README, this creates a visual progress indicator. In issues, the checkboxes are actually interactive.

## Collapsible sections in GitHub Markdown

Wrap content in `<details>` for a collapsible section — useful for long code examples, output, or supplementary information in READMEs and issues:

```markdown
<details>
<summary>Click to expand: Full error output</summary>

```
Error: ENOENT: no such file or directory, open '/etc/config.yaml'
    at Object.openSync (fs.js:462:3)
```plaintext

The full stack trace was 200 lines.
</details>
```

GitHub renders this as a collapsed "Click to expand" section.

## Definition lists (non-standard but widely supported)

Some parsers (kramdown, Pandoc) support definition lists:

```markdown
Term 1
:   Definition of term 1

Term 2
:   First definition
:   Second definition
```

This is not in the standard Markdown spec but is supported by Jekyll/GitHub Pages, some static site generators, and can be useful in documentation.

## Tables

```markdown
| Column 1 | Column 2 | Column 3 |
|----------|----------|----------|
| Row 1    | Value    | Value    |
| Row 2    | Value    | Value    |
```

Column alignment:

```markdown
| Left     | Center  | Right    |
|:---------|:-------:|---------:|
| aligned  | aligned | aligned  |
```

The `:` in the separator row controls alignment: `:---` = left, `:---:` = center, `---:` = right.

**Tip**: tables are valid HTML inside Markdown. If you need complex tables (merged cells, complex styles), use raw HTML. It will be preserved by most parsers.

## Footnotes (extended Markdown)

```markdown
This is a claim that needs a source.[^1]

[^1]: Source: Research paper title, Author, 2024.
```

Supported by Pandoc, GitHub, and many documentation tools. Footnote references are converted to superscript numbers that link to the footnote definition.

## Hard line breaks

In standard Markdown, a single newline in text produces no line break in the output. To force a line break:
- End the line with two spaces + newline (invisible, fragile)
- Use `\` at the end of the line (GFM only)
- Use a blank line to start a new paragraph (most reliable)

If you're writing prose and want visual paragraphs, use blank lines between them — they're semantically meaningful and universally supported.

## Escaping Markdown characters

Use a backslash to escape characters that would otherwise be interpreted as Markdown:

```markdown
\*This is not italic\*
\# This is not a heading
\[This is not a link\]
```

Useful when writing about Markdown itself or when your text naturally contains these characters.

## Inline HTML

Standard Markdown allows inline HTML. This is useful for:

```markdown
<kbd>Ctrl</kbd> + <kbd>S</kbd> to save

<mark>highlighted text</mark>

<sub>subscript</sub> and <sup>superscript</sup>

<br> for forced line breaks that work everywhere
```

These render in GitHub READMEs, documentation sites, and most Markdown processors. Don't overuse it — if you're writing a lot of raw HTML, you may want a different format.

## Converting Markdown to HTML

To see exactly how your Markdown will render — or to generate HTML from a Markdown file for embedding in a website — the [Markdown to HTML Converter](https://snappytools.app/markdown-to-html/) renders GitHub Flavored Markdown in the browser. Useful for previewing complex tables, code blocks, and task lists before committing.

## Tips for writing Markdown that renders everywhere

- Use fenced code blocks with language hints (not 4-space indentation) — wider support
- Keep table cells simple — avoid line breaks or complex content inside cells
- Test your README on GitHub's actual renderer before finalising (not just your local editor preview)
- Use ATX-style headings (`# Heading`) rather than setext style (`Heading\n=====`) — more consistent across parsers
- Prefer `*` for bullet lists and `**bold**` over `__bold__` — fewer edge cases

---

Markdown's strength is that 90% of what you write renders identically everywhere. The remaining 10% — footnotes, definition lists, collapsible sections — varies by parser. For documentation you control the stack for, use them freely. For content that will live on external platforms (GitHub, Dev.to, Notion), test or stick to the GFM subset.

Password Entropy: The Math Behind Why 'Password123' Is Weak

Snappy Tools — Sat, 02 May 2026 10:35:01 +0000

When a password manager or security tool tells you a password is "weak" or "strong", it's usually measuring entropy. Here's what entropy means, how to calculate it, and why it matters more than complexity requirements.

What is password entropy?

Entropy, in this context, measures the unpredictability of a password — specifically, how much information an attacker would need to guess it. It's measured in bits.

The formula:

entropy = log₂(pool_size) × password_length

Where pool_size is the number of possible characters.

For an 8-character password using only lowercase letters (26 characters):

entropy = log₂(26) × 8 = 4.7 × 8 ≈ 37.6 bits

For an 8-character password using lowercase + uppercase + digits + symbols (95 characters):

entropy = log₂(95) × 8 = 6.57 × 8 ≈ 52.5 bits

Higher entropy = more guesses needed to crack = stronger password.

Why length beats complexity

This is where most password policies get it wrong. Mandatory complexity rules (must include uppercase, lowercase, number, symbol) sound strict but often produce predictable patterns: Password1!, Summer2024!, Company@123.

Compare two passwords:

P@ssw0rd! — 9 characters, meets most complexity requirements, ~35 bits of actual entropy (because the pattern is predictable)
correct-horse-battery-staple — 29 characters, only lowercase and hyphens, ~152 bits of actual entropy

A random 12-character password using all character types has about 79 bits of entropy. A random 4-word passphrase from a 7,776-word dictionary (like Diceware) has:

log₂(7776) × 4 = 12.9 × 4 ≈ 51.7 bits

...but it's far more memorable.

The cracking time perspective

Entropy translates to guessing time. Modern hardware can test about 100 billion MD5 hashes per second. With 37.6 bits of entropy:

2^37.6 ≈ 200 billion combinations
200 billion / 100 billion per second = 2 seconds

A 37-bit password can be cracked in seconds offline. With 52 bits:

2^52 ≈ 4.5 quadrillion combinations
4.5 quadrillion / 100 billion per second ≈ 12.5 hours

With 80 bits (roughly what a good random 12-character password with full character set gives you):

2^80 ≈ 1.2 × 10^24 combinations
1.2 × 10^24 / 10^11 per second ≈ 380 billion years

At 80 bits, cracking the password by brute force is computationally infeasible with any foreseeable technology.

The practical threshold: aim for at least 80 bits of entropy for passwords you want to be secure long-term. For low-stakes passwords, 50–60 bits is usually fine.

The difference between theoretical and actual entropy

The formula assumes the password is chosen uniformly at random from the full pool. Human-chosen passwords have much lower actual entropy:

Substitutions are predictable: users replace 'a' with '@', 'o' with '0', 'e' with '3'
Appending numbers is predictable: password1, password123
Capitalizing the first letter is the most common pattern
Adding ! at the end is the second most common appended character

Password cracking tools use these patterns first. A password that looks like it has 60 bits of theoretical entropy may have only 20 bits of practical entropy if it follows predictable rules.

This is why a truly random password generated by a computer (not chosen by a human) is far stronger than a human-chosen password that "looks" complex.

How our password generator measures entropy

The Password Generator shows the entropy of each generated password and a strength indicator:

Under 50 bits: weak (offline cracking possible)
50–60 bits: okay for low-risk accounts
60–80 bits: good
80+ bits: very strong

The generator uses crypto.getRandomValues() — the Web Cryptography API's cryptographically secure random number generator. This ensures the passwords have the theoretical maximum entropy for their length and character set.

Bcrypt, scrypt, Argon2: slowing down the attacker

Even with a strong password, the cracking speed depends on how the password is stored. With MD5 or SHA-1 (common legacy choices), attackers can test 100 billion guesses per second. With bcrypt (cost factor 12), that drops to about 1,000 guesses per second.

This makes the entropy math dramatically better. At bcrypt cost 12:

50 bits of entropy → 2^50 / 1000 ≈ 35 billion seconds ≈ 1,100 years

Never store passwords with MD5, SHA-1, or plain SHA-256. Use bcrypt, scrypt, or Argon2. These are specifically designed to be slow, resisting bulk cracking even when the hash database is stolen.

Password entropy in practice

For users:

Use a password manager (LastPass, 1Password, Bitwarden) — it generates and stores truly random passwords
Aim for at least 16 characters for any important account
Each password must be unique — reuse compounds the damage from any single breach

For developers:

Store passwords with bcrypt (cost ≥ 10) or Argon2id
Never enforce maximum password length (it prevents long passphrases)
Enforce minimum length (12+ characters) rather than complexity rules
Check against known breach databases at login (e.g., HaveIBeenPwned API)

Password security is ultimately about making the attacker's job computationally expensive. Entropy tells you how expensive. The combination of high-entropy passwords (generated randomly, not chosen by humans) and slow hash functions (bcrypt, Argon2) is what makes credential cracking economically infeasible, even after a database is stolen.