DEV Community: Snappy Tools

CSS Box Shadow: The Complete Guide with Examples

Snappy Tools — Sat, 20 Jun 2026 10:03:38 +0000

CSS box-shadow is one of those properties that looks simple on the surface but has surprising depth. This guide covers everything from the basics to multi-layer shadows, inset shadows, and performance considerations — with ready-to-copy examples throughout.

The Syntax

box-shadow: [offset-x] [offset-y] [blur-radius] [spread-radius] [color];

Each value:

offset-x — horizontal shift (positive = right, negative = left)
offset-y — vertical shift (positive = down, negative = up)
blur-radius — higher = softer/larger shadow (can't be negative)
spread-radius — expands or contracts the shadow before blur
color — any valid CSS colour, including rgba() for transparency

Two values are the minimum required: offset-x and offset-y.

/* Minimal shadow */
box-shadow: 4px 4px black;

/* Typical card shadow */
box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15);

Common Shadow Patterns

Soft / Subtle

Best for cards and containers where you want depth without drama.

box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1), 0 1px 2px rgba(0, 0, 0, 0.06);

Raised / Button

Makes an element look clickable — like a physical button.

box-shadow: 0 4px 6px rgba(0, 0, 0, 0.1), 0 2px 4px rgba(0, 0, 0, 0.06);

Floating / Elevated

For modals, dropdowns, or any element that should appear above the page.

box-shadow: 0 10px 25px rgba(0, 0, 0, 0.15), 0 4px 10px rgba(0, 0, 0, 0.1);

Deep / Strong

Dramatic elevation — use sparingly.

box-shadow: 0 20px 60px rgba(0, 0, 0, 0.3), 0 6px 20px rgba(0, 0, 0, 0.2);

Inset Shadow

Renders the shadow inside the element, giving a pressed or sunken look.

box-shadow: inset 0 2px 6px rgba(0, 0, 0, 0.15);

Useful for input fields, toggle wells, or pressed button states.

Multi-Layer Shadows

You can stack multiple shadows by comma-separating them. They render front-to-back (first value is on top).

/* Two-layer shadow: tight dark + wide light */
box-shadow:
  0 2px 4px rgba(0, 0, 0, 0.2),
  0 8px 24px rgba(0, 0, 0, 0.1);

Multi-layer shadows look more natural than a single shadow because real-world light creates both a sharp contact shadow near the object and a soft diffuse shadow further away.

Spread Radius in Practice

The spread radius is often misunderstood. Positive spread expands the shadow before blur is applied; negative shrinks it.

/* Outline effect (0 blur, spread only) */
box-shadow: 0 0 0 3px #3b82f6;

/* Negative spread + large offset = shadow only at bottom */
box-shadow: 0 8px 10px -5px rgba(0, 0, 0, 0.3);

The 0 0 0 Xpx color pattern is a useful trick for adding a coloured ring/outline to any element — including images — without affecting layout (unlike outline, which can be clipped).

Colour and Opacity

Avoid hardcoded black shadows. Use rgba() with low alpha for realistic depth:

/* Too harsh */
box-shadow: 0 4px 8px black;

/* Natural */
box-shadow: 0 4px 8px rgba(0, 0, 0, 0.15);

For coloured glow effects (useful for interactive elements):

/* Green glow */
box-shadow: 0 0 12px rgba(34, 197, 94, 0.5);

/* Blue focus ring */
box-shadow: 0 0 0 3px rgba(59, 130, 246, 0.4);

Transition and Animation

box-shadow is animatable. Combine with :hover or :focus transitions for responsive depth:

.card {
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.1);
  transition: box-shadow 0.2s ease;
}

.card:hover {
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.15);
}

Keep transitions under 300ms. Longer delays feel sluggish.

Performance Notes

box-shadow triggers the browser's composite layer — it is painted, not composited. This means:

Animating box-shadow is more expensive than animating transform or opacity
For animation-heavy UIs, use a pseudo-element with opacity transition as a workaround:

.card::after {
  content: '';
  position: absolute;
  inset: 0;
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.2);
  opacity: 0;
  transition: opacity 0.2s ease;
}

.card:hover::after {
  opacity: 1;
}

This way you animate opacity (GPU-composited) instead of box-shadow directly.

Dark Mode Shadows

Box shadows over dark backgrounds often disappear or look harsh. Options:

Use rgba() white shadows for a subtle emboss/lift effect
Reduce shadow opacity — a 0.5 alpha shadow that works on light needs ~0.15 on dark
Add a border instead — often cleaner on dark UIs

@media (prefers-color-scheme: dark) {
  .card {
    box-shadow: 0 1px 3px rgba(0, 0, 0, 0.3);
    border: 1px solid rgba(255, 255, 255, 0.08);
  }
}

Quick Reference

Pattern	CSS
Soft card	`0 1px 3px rgba(0,0,0,0.1)`
Raised button	`0 4px 6px rgba(0,0,0,0.1)`
Floating modal	`0 10px 25px rgba(0,0,0,0.15)`
Inset (pressed)	`inset 0 2px 4px rgba(0,0,0,0.1)`
Focus ring	`0 0 0 3px rgba(59,130,246,0.4)`
Coloured glow	`0 0 12px rgba(34,197,94,0.5)`

Try It Live

Rather than tweaking values by hand, use a visual box shadow generator to dial in the exact look you want. SnappyTools CSS Box Shadow Generator lets you add up to 4 independent shadow layers with live preview, export as CSS, and start from one of 5 presets — all in the browser with no signup required.

Box shadows are one of the easiest ways to add depth and polish to a UI. Master the multi-layer approach and the rgba() opacity technique, and you'll stop reaching for border hacks to create the same effect.

NIST Password Guidelines 2024: What Every Developer Needs to Know

Snappy Tools — Fri, 19 Jun 2026 10:07:15 +0000

If you're still telling users to include "at least one uppercase letter, one number, and one special character," you're following outdated advice. The National Institute of Standards and Technology (NIST) updated their password guidance significantly in 2024, and the changes are worth knowing — especially if you build or maintain authentication systems.

What Is NIST SP 800-63B?

NIST Special Publication 800-63B is the US federal standard for digital identity and authentication. It's not just for government systems — it's widely cited as the gold standard for password policy in private industry. The fourth revision (800-63B-4) was published in 2024, building on the landmark 2017 update that first reversed decades of conventional wisdom about passwords.

The 2024 Updates: What Changed

Minimum length raised to 15 characters

The 2017 guidance set the minimum at 8 characters. The 2024 revision raises this to 15 characters for user-chosen passwords. The maximum must be at least 64 characters — and verifiers must not truncate passwords beyond this length.

All Unicode is now allowed

Passwords must support all printable Unicode characters, including spaces and emoji. A password like correct horse battery staple (with spaces) is valid and encouraged. This matters for internationalization — non-English users often use characters from their own language in memorable passphrases.

Mandatory breach checking

New passwords must be checked against known-compromised lists. The HaveIBeenPwned API provides a free, privacy-preserving k-anonymity endpoint for this. If a user submits a password found in a breach dataset, reject it with a clear message — not a generic "password is too weak" error.

SMS OTP is downgraded

SMS-based one-time passwords are no longer considered acceptable for high-assurance applications. SMS is vulnerable to SIM-swapping attacks and SS7 protocol weaknesses. NIST now recommends authenticator apps (TOTP) or passkeys instead.

Periodic rotation is explicitly banned

This deserves emphasis: do not force users to change passwords on a schedule. The research is clear — forced rotation leads to predictable changes (Password1 → Password2 → Password3) and makes security worse. Only require a password change if there's evidence of compromise.

What NIST Says to Stop Doing

These practices are explicitly discouraged in 800-63B:

Complexity rules: Requiring uppercase + lowercase + number + symbol. These push users toward predictable substitutions (P@ssw0rd) rather than genuinely random passwords.
Password hints: Storing hints that make guessing easier.
Knowledge-based authentication: Security questions ("What was the name of your first pet?") are banned for high-assurance applications.
Truncating passwords: Never silently truncate a password that meets the maximum length. This is a security vulnerability.
Password expiration timers: Without evidence of compromise, rotating passwords reduces security.

What Good Password Policy Looks Like in 2024

If you're building an auth system or updating your password policy, here's the NIST-aligned checklist:

Accept passwords 15–64+ characters (set your DB column to 255 to be safe)
Accept all printable characters including spaces — don't strip or reject Unicode
Hash with bcrypt, Argon2, or scrypt — never MD5, SHA-1, or unsalted SHA-256
Check against breach databases at registration and optionally on login
No complexity rules — length is the only mandatory requirement
No periodic expiration — only reset on confirmed breach
Rate-limit login attempts — throttle or lockout after repeated failures
Offer MFA — TOTP or passkeys, not SMS

A Note on Entropy

The reason NIST focuses on length rather than complexity is entropy. Password strength is measured in bits of entropy — how many guesses would it take to crack it.

8-character all-lowercase: ~38 bits
8-character with complexity rules: ~52 bits (strong for a 2005 attack, weak today)
16-character random (mixed): ~105 bits
20-character random (mixed): ~131 bits — exceeds AES-128 security level

A random 16-character password generated by a cryptographically secure generator is practically uncrackable by brute force. The real risks are phishing, credential stuffing, and insecure storage — not brute force.

For generating properly random passwords, use this free password generator — it uses window.crypto.getRandomValues() (the same CSPRNG your browser uses for HTTPS) and runs entirely in your browser. No data is ever sent to a server.

How to Check If a Password Has Been Breached

The HaveIBeenPwned API uses k-anonymity: you send only the first 5 characters of the SHA-1 hash of the password, and the API returns all matching hash suffixes. Your server (or client) checks if the full hash appears in the list. The password itself never leaves the user's device.

import hashlib
import urllib.request

def is_pwned(password: str) -> int:
    sha1 = hashlib.sha1(password.encode()).hexdigest().upper()
    prefix, suffix = sha1[:5], sha1[5:]
    url = f"https://api.pwnedpasswords.com/range/{prefix}"
    response = urllib.request.urlopen(url).read().decode()
    for line in response.splitlines():
        hash_suffix, count = line.split(":")
        if hash_suffix == suffix:
            return int(count)
    return 0

count = is_pwned("password123")
print(f"Found in {count} breaches" if count else "Not found in known breaches")

Run this check at password creation and optionally on login. If the count is > 0, reject the password with a message like: "This password appeared in a known data breach. Please choose a different one."

Summary

NIST's 2024 guidance in three sentences: Use long random passwords. Stop adding friction that doesn't improve security. Check passwords against known breach databases.

For most developers, the key action item is to stop enforcing complexity rules that frustrate users without improving security, and to add HaveIBeenPwned integration to your registration flow.

Need to generate strong random passwords for testing, provisioning, or personal use? SnappyTools Password Generator runs entirely in your browser with no server calls — 8 to 128 characters, customisable character sets, and up to 10 passwords at once.

What Is the Automated Readability Index (ARI)? A Developer's Guide

Snappy Tools — Thu, 18 Jun 2026 10:03:55 +0000

If you've ever needed to score the readability of a piece of text programmatically, you've probably encountered the Flesch-Kincaid formula. But there's a lesser-known formula that's actually faster to compute and produces similarly accurate results: the Automated Readability Index, or ARI.

This post explains what ARI is, how the formula works, how it compares to other readability metrics, and when to use it.

What Is the Automated Readability Index?

The Automated Readability Index (ARI) is a readability formula developed in 1967 for the US Air Force to evaluate the readability of technical documents and training manuals. It was designed to be computed automatically — without human syllable counting.

The formula is:

ARI = 4.71 × (characters / words) + 0.5 × (words / sentences) − 21.43

The result is a number that maps directly to a US school grade level:

ARI Score	Grade Level	Age Range
1	Kindergarten	5–6
2	1st Grade	6–7
3	2nd Grade	7–8
4	3rd Grade	8–9
5	4th Grade	9–10
6	5th Grade	10–11
7	6th Grade	11–12
8	7th Grade	12–13
9	8th Grade	13–14
10	9th Grade	14–15
11	10th Grade	15–16
12	11th Grade	16–17
13	12th Grade	17–18
14	College	18–22

Why Characters Instead of Syllables?

Most readability formulas (Flesch-Kincaid, Gunning Fog, SMOG) use syllable counts. Counting syllables accurately requires linguistic knowledge — you need a pronunciation dictionary or a syllabification algorithm.

ARI sidesteps this entirely. It uses character count per word instead. The reasoning: longer words (more characters) tend to have more syllables and be harder to read — so character count is a reasonable proxy, and it's trivially easy to compute.

In Python, implementing ARI from scratch takes about 10 lines:

import re

def calculate_ari(text):
    sentences = len(re.split(r'[.!?]+', text.strip()))
    words = len(text.split())
    chars = sum(c.isalnum() for c in text)
    if words == 0 or sentences == 0:
        return 0
    return 4.71 * (chars / words) + 0.5 * (words / sentences) - 21.43

No syllable dictionary required.

ARI vs. Flesch-Kincaid Grade Level

Both ARI and Flesch-Kincaid Grade Level output a US school grade number. How do they compare?

For most English text, they agree closely — typically within 0.5–1.5 grade levels.

The difference emerges with words that are long but phonetically simple. Consider "algorithm": it has 9 characters but only 3 syllables. Flesch-Kincaid treats it as a moderately complex word; ARI treats it as more complex because of its character length. This means ARI tends to score slightly higher than Flesch-Kincaid for texts heavy in technical vocabulary.

For everyday prose, the difference is negligible. Choose based on your use case:

ARI: faster to compute, no syllable detection needed, designed for technical writing
Flesch-Kincaid: more established in academic and educational publishing, better for literary analysis

Target ARI Scores by Content Type

Content Type	Target ARI
Children's content	3–5
General web content	6–9
Marketing emails	6–8
News articles	8–10
Business reports	10–12
Technical documentation	12–14
Academic papers	14–18+

Implementing ARI in Other Languages

JavaScript:

function calculateARI(text) {
  const sentences = text.split(/[.!?]+/).filter(s => s.trim()).length;
  const words = text.trim().split(/\s+/).length;
  const chars = text.replace(/[^a-zA-Z0-9]/g, '').length;
  if (!words || !sentences) return 0;
  return 4.71 * (chars / words) + 0.5 * (words / sentences) - 21.43;
}

Go:

import (
    "regexp"
    "strings"
    "unicode"
)

func calculateARI(text string) float64 {
    sentenceRe := regexp.MustCompile(`[.!?]+`)
    sentences := len(sentenceRe.Split(strings.TrimSpace(text), -1))
    words := len(strings.Fields(text))
    chars := 0
    for _, r := range text {
        if unicode.IsLetter(r) || unicode.IsDigit(r) {
            chars++
        }
    }
    if words == 0 || sentences == 0 {
        return 0
    }
    return 4.71*float64(chars)/float64(words) + 0.5*float64(words)/float64(sentences) - 21.43
}

When Should You Use ARI?

ARI is a good choice when:

You need a fast computation — no syllable dictionary, just character counting
You're analysing technical writing — ARI was designed for this use case
You're building a readability pipeline — ARI integrates cleanly as one of several metrics
You need a grade-level output — ARI maps directly to US grade levels without additional conversion

If you want to run an ARI check on a piece of text right now without writing any code, you can use a free ARI checker online that calculates ARI alongside Flesch-Kincaid, Gunning Fog, SMOG, and Coleman-Liau — all in one pass, no signup.

Summary

The Automated Readability Index is a 1967 formula designed for fast, automatic readability scoring. It uses character-per-word ratios instead of syllable counts, making it simpler to implement than most alternatives. For most English texts, it produces results very close to Flesch-Kincaid Grade Level.

If you're building a readability scoring feature and want something lightweight with no linguistic dependencies, ARI is worth considering.

Why Your Word Counter Gives Different Results Than Others (And How They All Work)

Snappy Tools — Wed, 17 Jun 2026 19:36:09 +0000

You paste the same text into two different word counters and get different results. It happens more often than you'd expect. Here's why — and how to know which count to trust.

The core problem: what is a "word"?

Every word counter has to answer this question, and there's no single right answer.

The most common approach is whitespace splitting: split the text on any space or line break, count the chunks. In JavaScript:

const wordCount = text.trim().split(/\s+/).filter(Boolean).length;

In Python:

word_count = len(text.split())

Both approaches count don't as one word, 2026 as one word, and well-known as one word. That's usually what you want.

But here's where they diverge:

Input	Whitespace split	Natural language tokenizer
`hello, world`	2 words	2 words
`don't`	1 word	1 word (usually)
`well-known`	1 word	2 words (sometimes)
`C++`	1 word	1 word
`$ 100.00`	2 words	2 words
`:-)`	1 word	0 words (some tools skip symbols)
(empty line)	0 words	0 words

Natural language tokenizers like Python's nltk.word_tokenize() or spaCy's tokenizer follow linguistic rules. They'll split I've into I and 've, which a whitespace splitter won't. This is why NLP tools often produce higher word counts than simple splitters.

Rule of thumb: For writing (blog posts, essays, social media), whitespace splitting is fine and produces consistent results. For NLP tasks (training data, linguistic analysis), use a proper tokenizer.

The character count you actually need to know

Most people check word count. But character count is what actually matters for most platforms — and it's where most people get tripped up.

Here are the limits that catch people out:

Platform	Limit	Gotcha
Twitter / X	280 characters	URLs always count as 23 chars
Google meta description	~155 characters	Truncates in search results
LinkedIn post	3,000 characters	Feed truncates at ~210 chars
Instagram caption	2,200 characters	Feed shows ~125 chars before "more"
YouTube description	5,000 characters	Shows ~100 chars in search results
Google Ads headline	30 characters	Hard limit, no truncation
Google Ads description	90 characters	Hard limit
App Store short description	80 characters	—
Facebook post	63,206 characters	Engagement drops after 80 chars
Facebook comment	8,000 characters	—

The Twitter URL rule is particularly confusing: whether you paste a 10-character URL or a 200-character URL, it counts as 23 characters in your post. X's own character counter handles this; most third-party tools don't.

Why "characters" is ambiguous too

When a platform says "280 characters", does it mean:

Bytes?
Unicode code points?
Grapheme clusters?

For most Western text, these are the same. But for emoji and some Unicode characters, they're not.

The fire emoji 🔥 is:

4 bytes (UTF-8)
1 Unicode code point (U+1F525)
1 grapheme cluster

Twitter counts each emoji as 2 characters (not 1, not 4). Most other platforms count it as 1.

A skin-tone modified emoji like 👍🏽 is:

Two Unicode code points (U+1F44D + U+1F3FD)
1 grapheme cluster (visually one emoji)

JavaScript's string.length counts it as 4 (because it uses UTF-16 with surrogate pairs). Twitter counts it as 2. Humans count it as 1.

This is why emoji-heavy content can produce surprising character counts depending on which tool you use.

The characters-to-words conversion

The standard estimate: 1 word ≈ 6 characters (5 letters average + 1 space).

This works well for conversational English. Adjust for:

Technical writing (long words like "authentication", "infrastructure"): closer to 7–8 chars/word, so 1,000 characters ≈ 130–145 words
Conversational/casual writing (lots of "the", "is", "a"): closer to 5 chars/word, so 1,000 characters ≈ 200 words
Code snippets or URLs: ratio breaks down entirely

Quick reference:

Characters	Words (approx.)
280	~45
500	~83
1,000	~165
2,000	~333
3,000	~500
5,000	~833
8,000	~1,333
10,000	~1,667

For an exact count for your specific text: SnappyTools Word Counter updates in real time and shows character counts for major platforms side by side.

Reading time: how accurate are the estimates?

Most tools use 200–225 words per minute as the reading speed average. Medium uses 275 wpm; some tools use 200 wpm. That's a 35% difference in estimated reading time for the same text.

The research is scattered. A 2019 meta-analysis by Brysbaert found the average silent reading speed is 238 words per minute for fiction and 260 wpm for non-fiction among proficient adult readers. But comprehension drops significantly above ~300 wpm for complex material.

Practical guideline for content creators:

Use 225 wpm as a conservative baseline
Add 20% for technical or dense content
Headlines, bullet points, and white space reduce perceived reading time — a 1,000-word structured how-to article reads faster than a 1,000-word wall of prose

The SEO word count myth

You've probably heard that longer content ranks better. This is partially true and frequently misapplied.

What actually correlates with higher rankings:

Topical completeness — does the content answer the query and related questions?
User intent match — is this what the searcher was looking for?
Dwell time — do readers stay and read?

What does not directly cause higher rankings:

Raw word count above the threshold needed to cover the topic

A 500-word page that completely answers "what is ARP poisoning" will beat a 3,000-word rambling page on the same topic. The first-page average word count for competitive queries is often cited as 1,500–2,000 words, but that's correlation: pages that thoroughly cover complex topics happen to be long, not the other way round.

Guideline: Write until the topic is covered, then stop. For simple factual queries, 300–600 words is often right. For comprehensive guides covering multiple subtopics, 1,500–3,000 words is common. Don't pad.

If you need a quick word, character, and reading time check with live platform limits: SnappyTools Word Counter — no signup, runs in the browser.

CSS Box Shadow: The Complete Guide (with Copy-Paste Examples)

Snappy Tools — Tue, 16 Jun 2026 10:08:40 +0000

The box-shadow property sounds simple — but once you start layering shadows, building card elevation systems, or trying to recreate that exact Figma drop shadow in CSS, the syntax gets complicated fast.

This guide covers everything from the basics to advanced multi-layer techniques, with copy-paste examples throughout.

The Basic Syntax

box-shadow: offset-x offset-y blur-radius spread-radius color;

Each part explained:

Parameter	What it does
`offset-x`	Horizontal position. Positive = right, negative = left
`offset-y`	Vertical position. Positive = down, negative = up
`blur-radius`	Edge softness. 0 = crisp, higher = more diffuse
`spread-radius`	Expands (+) or contracts (−) the shadow before blur
`color`	Any valid CSS color, usually `rgba()` for opacity control

A simple card shadow:

.card {
  box-shadow: 0 4px 16px rgba(0, 0, 0, 0.12);
}

Inset Shadows

Add the inset keyword to flip the shadow inside the element — useful for pressed button states and recessed input fields:

/* Pressed button */
.btn:active {
  box-shadow: inset 0 2px 6px rgba(0, 0, 0, 0.2);
}

/* Recessed input field */
input {
  box-shadow: inset 0 2px 4px rgba(0, 0, 0, 0.1);
}

Multiple Shadow Layers

You can stack multiple shadows with a comma-separated list. The first shadow is drawn on top (closest to the element):

.card {
  box-shadow:
    0 1px 3px rgba(0, 0, 0, 0.12),   /* tight inner shadow for crispness */
    0 6px 24px rgba(0, 0, 0, 0.08);  /* wide outer shadow for ambient depth */
}

This two-layer pattern mimics how real shadows work — a bright direct light source creates a sharp inner shadow, while ambient light creates a soft outer glow.

The Four Elevation Levels

Here's a practical elevation scale for UI design:

/* Flat — default state */
.elevation-0 {
  box-shadow: none;
}

/* Subtle — cards, sections */
.elevation-1 {
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.10), 0 2px 8px rgba(0, 0, 0, 0.06);
}

/* Standard — hover state, dropdowns */
.elevation-2 {
  box-shadow: 0 4px 12px rgba(0, 0, 0, 0.12), 0 8px 24px rgba(0, 0, 0, 0.08);
}

/* Elevated — modals, dialogs */
.elevation-3 {
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.14), 0 16px 48px rgba(0, 0, 0, 0.10);
}

Glow Effects

Set both offsets to 0 and use a saturated colour for a glow:

/* Green glow */
.btn-primary:focus {
  box-shadow: 0 0 0 3px rgba(47, 133, 90, 0.4);
}

/* Stacked glow for stronger effect */
.notification-badge {
  box-shadow:
    0 0 8px rgba(229, 62, 62, 0.5),
    0 0 24px rgba(229, 62, 62, 0.25);
}

Using box-shadow as a Border

box-shadow can replace a border without affecting layout — useful for focus rings and outlines:

/* Focus ring that respects border-radius */
button:focus-visible {
  outline: none;
  box-shadow: 0 0 0 3px rgba(66, 153, 225, 0.6);
}

/* 2px green border without layout shift */
.selected-card {
  box-shadow: 0 0 0 2px #2f855a;
}

Neumorphism

The neumorphic trend uses two shadows in opposite directions on a matching background:

/* Element background must match --surface */
:root {
  --surface: #e0e5ec;
}

.neumorphic {
  background: var(--surface);
  box-shadow:
    9px 9px 16px #b8bec7,    /* dark shadow — bottom-right */
    -9px -9px 16px #ffffff;  /* light shadow — top-left */
}

/* Pressed state */
.neumorphic:active {
  box-shadow:
    inset 4px 4px 8px #b8bec7,
    inset -4px -4px 8px #ffffff;
}

Animating box-shadow

Animating box-shadow directly triggers a repaint on every frame. For smooth hover transitions, it's still acceptable for most UI:

.card {
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.10);
  transition: box-shadow 0.2s ease, transform 0.2s ease;
}

.card:hover {
  box-shadow: 0 8px 24px rgba(0, 0, 0, 0.15);
  transform: translateY(-2px);
}

For high-frequency animations (scroll-tied effects), animate opacity on a ::after pseudo-element instead — this stays on the compositor layer.

box-shadow vs filter: drop-shadow()

	`box-shadow`	`filter: drop-shadow()`
Follows	Element's box	Actual rendered shape
Supports `inset`	✅	❌
Supports spread	✅	❌
Multiple layers	✅ (comma list)	❌ (wrap in multiple elements)
Best for	Buttons, cards, divs	Transparent PNGs, SVGs

Converting Figma Shadows to CSS

Figma's shadow panel maps directly to CSS:

X → offset-x
Y → offset-y
Blur → blur-radius
Spread → spread-radius
Colour + opacity → rgba() or hsla()
Inner Shadow → add inset keyword

Quick Reference: Common Patterns

/* Soft card */
box-shadow: 0 1px 3px rgba(0,0,0,0.10), 0 2px 8px rgba(0,0,0,0.06);

/* Material elevation 2 */
box-shadow: 0 1px 2px rgba(0,0,0,0.12), 0 2px 4px rgba(0,0,0,0.08);

/* Modal / dialog */
box-shadow: 0 8px 32px rgba(0,0,0,0.15), 0 20px 64px rgba(0,0,0,0.10);

/* Focus ring */
box-shadow: 0 0 0 3px rgba(66,153,225,0.5);

/* Inset (pressed button) */
box-shadow: inset 0 2px 4px rgba(0,0,0,0.15);

/* Neumorphic (on #e0e5ec background) */
box-shadow: 9px 9px 16px #b8bec7, -9px -9px 16px #ffffff;

/* Remove shadow */
box-shadow: none;

Building Shadows Without Guessing

If you'd rather adjust sliders than type raw CSS, the CSS Box Shadow Generator at SnappyTools gives you a live preview with multi-layer support, Figma-style controls, and a one-click copy button. No install, runs 100% in the browser.

The key insight with box-shadow is that single-layer shadows look flat. Stack a tight, slightly opaque shadow with a wider, more transparent one — and you get depth that actually looks right.

Open Graph Meta Tags: What They Are and How to Generate Them Correctly

Snappy Tools — Mon, 15 Jun 2026 10:11:20 +0000

When someone shares a link on Twitter/X, Facebook, LinkedIn, or Slack, you see a preview card with a title, description, and image. Those cards are powered by Open Graph meta tags — small HTML snippets in your page's <head>.

Getting them right is one of the highest-leverage quick wins in web development. A good social preview dramatically increases click-through rate.

The Core Tags

At minimum, every page needs these four:

<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A 1–2 sentence description of the page." />
<meta property="og:image" content="https://yourdomain.com/og-image.jpg" />
<meta property="og:url" content="https://yourdomain.com/this-page/" />

Four tags. That's it. They get you a functional preview on every major platform.

Extended Tags Worth Adding

<meta property="og:type" content="website" />
<!-- Use "article" for blog posts, "product" for e-commerce -->

<meta property="og:site_name" content="Your Site Name" />
<!-- Appears below the title on some platforms -->

<meta name="twitter:card" content="summary_large_image" />
<!-- Makes Twitter use a large image preview instead of a small thumbnail -->

<meta name="twitter:title" content="Your Page Title" />
<meta name="twitter:description" content="A 1–2 sentence description." />
<meta name="twitter:image" content="https://yourdomain.com/og-image.jpg" />

The twitter: tags are separate because Twitter/X has its own spec. In practice, Twitter falls back to og: tags when twitter: tags are absent — but specifying both gives you more control over the Twitter card format.

The og:image Tag: Most Common Mistakes

Wrong size: og:image should be at least 1200 × 630 pixels. Smaller images appear blurry or get cropped.

Relative URL: The og:image value must be an absolute URL (https://...). Relative paths (/images/preview.jpg) don't work for social crawlers.

Slow load: Social platform crawlers time out quickly. Your og:image should load fast and be under 300 KB. JPEG works best for photographic images.

Aggressive caching: Facebook and LinkedIn cache og:image heavily. After changing it, use their debugging tools (Facebook Sharing Debugger, LinkedIn Post Inspector) to force a re-scrape.

Verifying Your Tags

Every major platform has an official scraping tool:

Facebook: developers.facebook.com/tools/debug/
LinkedIn: linkedin.com/post-inspector/inspect/
Twitter/X: Paste in Twitter cards validator
Slack: Just paste the URL into a Slack message — it unfurls automatically

These show you exactly what the platform sees, including which tags it picks up and what the preview will look like.

Dynamic OG Tags in Common Frameworks

Next.js (App Router):

export const metadata = {
  title: 'My Page',
  openGraph: {
    title: 'My Page',
    description: 'Page description',
    images: [{ url: 'https://yourdomain.com/og-image.jpg' }],
  },
};

WordPress: Yoast SEO generates OG tags automatically from your page title and featured image.

Static HTML: Add the tags manually to each page's <head>.

Generating the Tags

Rather than writing the HTML by hand, SnappyTools has a free Open Graph Meta Tag Generator that lets you fill in a form, previews the card for Twitter/X, Facebook, and LinkedIn, and outputs the complete tag block to paste into your <head>. No login, runs in your browser.

tl;dr: Four tags get you functional social previews everywhere. Add twitter:card: summary_large_image for a large Twitter preview. Make your og:image 1200 × 630px, absolute HTTPS URL, under 300 KB.

URL Slugs Explained: How to Write Clean, SEO-Friendly URLs Every Time

Snappy Tools — Sun, 14 Jun 2026 15:45:22 +0000

Every URL you publish is either working for you or against you. Most developers get this right by default — lowercase, hyphens, no garbage parameters. But a surprising number of sites still publish URLs like /post?id=8472 or /2026/06/14/untitled-draft-final-v3-copy. This guide is about doing it right the first time.

What Is a URL Slug?

The slug is the human-readable part of a URL that identifies a specific page. In:

https://snappytools.app/keyword-density-checker/

The slug is keyword-density-checker.

A well-formed slug is lowercase, uses hyphens to separate words, and contains only the words that matter — no filler, no punctuation, no auto-generated noise.

Why Slugs Matter for SEO

Google reads URLs as a signal. A slug that matches your target keyword tells the crawler exactly what the page is about before it even reads the content. It's a small signal, but every small signal adds up.

More importantly: URLs appear in search results. A clean slug like /how-to-write-a-cover-letter/ tells the user what they'll get before they click. A messy slug like /p/46173 tells them nothing. Click-through rates reflect this.

Three practical rules:

Match the slug to your page's primary keyword phrase
Use hyphens, never underscores (Google treats underscores as word joiners: my_page reads as mypage)
Remove stop words (a, an, the, and, or) unless they're essential to meaning

The Common Mistakes

Too long: /how-i-discovered-that-the-best-approach-to-writing-short-urls-is-to-remove-unnecessary-words/

Keep it under 5-6 words where possible. Trim everything that doesn't add meaning.

Auto-generated noise: /blog/2026/06/14/post-title-here-draft-revised-final/

Dates in URLs cause problems when content is evergreen — the URL signals the content is old even when the information is still current. Unless your content is explicitly time-sensitive (news, changelogs), skip the date.

Keyword stuffing: /free-best-online-keyword-density-tool-seo-checker-2026/

This looks manipulative and reads badly. One clear keyword phrase per slug, stated naturally.

Spaces encoded as %20: /my%20blog%20post/

Always replace spaces with hyphens during URL generation. Most CMS platforms do this automatically, but if you're building custom routes, handle it explicitly.

How to Generate Good Slugs Programmatically

The algorithm is simple:

function slugify(text) {
  return text
    .toLowerCase()
    .normalize('NFD')               // decompose accented chars
    .replace(/[̀-ͯ]/g, '') // strip accent marks
    .replace(/[^a-z0-9\s-]/g, '')   // remove non-alphanumeric
    .trim()
    .replace(/\s+/g, '-')           // spaces → hyphens
    .replace(/-+/g, '-');           // collapse multiple hyphens
}

slugify("What Is a URL Slug? (Complete Guide)")
// → "what-is-a-url-slug-complete-guide"

For production, you may also want to remove stop words:

const STOP_WORDS = new Set(['a', 'an', 'the', 'and', 'or', 'but', 'in', 'on', 'at', 'to', 'for', 'of', 'with', 'by', 'from', 'is', 'are', 'was', 'were']);

function slugifyWithoutStopWords(text) {
  const words = text.toLowerCase().split(/\s+/);
  const filtered = words.filter(w => !STOP_WORDS.has(w));
  return filtered.join('-').replace(/[^a-z0-9-]/g, '');
}

slugifyWithoutStopWords("What Is a URL Slug and Why Does It Matter")
// → "what-url-slug-why-does-matter"

Whether to strip stop words depends on the phrase. "How to write a blog post" without stop words becomes "write-blog-post" — shorter, but loses the "how to" intent signal that might matter for specific queries. Test before deciding.

When to Update a Slug

Generally: don't. Changing a URL breaks incoming links, accumulated PageRank, and any bookmarks or social shares pointing at the old URL. If you must change it, set up a 301 redirect from the old URL to the new one immediately.

The one exception: if a slug contains a time-bound keyword ("best-tools-2024") and you're updating the page annually, it's worth updating the slug and redirecting the old one. Just automate the redirect so you don't forget.

Quick Checklist Before Publishing

[ ] Lowercase only
[ ] Hyphens as word separators (not underscores, not spaces)
[ ] Primary keyword included
[ ] Stop words removed (unless they alter meaning)
[ ] Under 60 characters
[ ] No dates unless the content is time-sensitive
[ ] No special characters, no percent-encoding

Tools That Help

If you're working with keyword-heavy content and want to see whether your slug and page copy are using your target phrase at the right density, SnappyTools Keyword Density Checker runs entirely in-browser with no upload required. Paste your content, enter your keyword, and you get exact frequency counts and density percentage instantly.

For content that goes into SEO-focused pages, SnappyTools Word Counter helps verify your content length and reading time before you publish.

Getting slugs right is one of those foundation tasks that costs almost nothing to do well and consistently costs you if you get it wrong. Set up the slugify function once, apply it everywhere, and move on to the things that are harder to automate.

How Many Words Is [X] Characters? A Complete Reference Guide

Snappy Tools — Sat, 13 Jun 2026 10:18:41 +0000

One of the most common questions content writers, developers, and social media managers ask is: "how many words is [X] characters?" Whether you're hitting a tweet limit, filling out a meta description, or scoping out a writing project, understanding the character-to-word relationship is genuinely useful.

Here's the complete reference, plus the rules that govern social platform limits.

The Formula

The standard English word is 4–5 characters long. Add one space between words, and you get roughly 5–6 characters per word. The most commonly used estimate:

6 characters per word (5-character average word + 1 space)

To convert: characters ÷ 6 ≈ words

This gives you a ballpark. Your actual count depends on writing style — conversational writing uses shorter words, technical writing uses longer ones. For an exact count, paste your text into a word counter.

Quick Reference Table

Characters	≈ Words	Context
150	~25	Google meta description (mobile)
155	~26	Google meta description (max safe)
200	~33	Short push notification
280	~47	Twitter/X post
300	~50	Short email reply
400	~67	Google Ads description
500	~83	LinkedIn update
600	~100	Short blog intro paragraph
700	~117	Two short paragraphs
750	~125	Instagram caption (before truncation)
850	~142	Brief product description
1,000	~167	Short FAQ answer
1,200	~200	Short news article summary
1,500	~250	App store description
1,700	~283	1-minute read
2,000	~333	Brief article or newsletter
2,500	~417	Medium-length FAQ
3,000	~500	Short blog post, LinkedIn max
4,000	~667	Typical how-to article section
5,000	~833	3-minute read
6,000	~1,000	Standard blog post
7,000	~1,167	Detailed tutorial
8,000	~1,333	Long-form article
9,000	~1,500	Pillar content / long post
10,000	~1,667	Long-form guide
12,000	~2,000	8-minute read

Platform-Specific Limits

Twitter / X

Posts: 280 characters (≈ 47 words)
Bio: 160 characters (≈ 27 words)

Posts: 3,000 characters (≈ 500 words)
Posts truncate in feed after ~210 characters — lead with a hook
Bio/About: 2,600 characters

Instagram

Captions: 2,200 characters
Captions truncate after 125 characters in feed — lead with the important part
Hashtags count toward the limit

Meta Descriptions (SEO)

Google truncates at roughly 155–160 characters on desktop
Mobile may truncate earlier, around 120 characters
Optimal range: 120–155 characters (≈ 20–26 words)

Page Titles (SEO)

Google typically shows 50–60 characters
Optimal range: 50–60 characters (≈ 8–10 words)
Titles longer than 60 characters get cut off with "..."

Facebook

Posts: 63,206 characters (no practical content limit)
Post truncate in feed after ~480 characters
Ad headline: 40 characters recommended
Ad description: 125 characters before truncation

YouTube

Video descriptions: 5,000 characters (≈ 833 words)
Only the first 100–150 characters show without clicking "Show more"
Channel description: 1,000 characters

Email (Subject Lines)

Gmail/Outlook preview: 60 characters on desktop, 30–40 on mobile
Optimal subject line: 40–50 characters (≈ 7–8 words)

Reading Time Estimates

These assume an average reading speed of 225 words per minute:

Characters	Words	Reading Time
1,350	~225	1 minute
2,700	~450	2 minutes
3,600	~600	~2.5 minutes
4,500	~750	~3 minutes
6,750	~1,125	5 minutes
13,500	~2,250	10 minutes

When You Need an Exact Count

The formula is useful for estimating, but for real work you need exact counts. Paste your content into the free Word Counter and you'll see:

Word count
Character count (with and without spaces)
Sentence and paragraph count
Estimated reading time
Platform-specific limits (Twitter/X, meta descriptions, LinkedIn, Instagram, and more) highlighted in real-time

It works entirely in your browser — no paste-and-lose-your-text, no account required.

Open Graph Tags Explained: Control How Your Pages Look When Shared

Snappy Tools — Fri, 12 Jun 2026 10:17:35 +0000

Every time someone shares a link on Twitter/X, LinkedIn, or Slack, a card appears with an image, title, and description. That card is controlled by Open Graph meta tags — and if you don't set them, the social platform guesses, usually badly.

What are Open Graph tags?

Open Graph (OG) is a protocol invented by Facebook that lets you control the "preview card" for your page when shared on social networks. You add <meta> tags to your page's <head>, and social platforms read them when generating the link preview.

<meta property="og:title" content="My Page Title">
<meta property="og:description" content="A one-sentence summary of the page.">
<meta property="og:image" content="https://example.com/og-image.png">
<meta property="og:url" content="https://example.com/my-page/">
<meta property="og:type" content="website">
<meta property="og:site_name" content="My Site">

The minimum required set

These four tags are the most important:

Tag	Purpose	Recommended
`og:title`	Card headline	Under 60 chars
`og:description`	Subtitle text	Under 155 chars
`og:image`	Preview image	1200×630px min
`og:url`	Canonical URL of the page	Full absolute URL

Without og:image, most platforms either show nothing or scrape a random image from the page. Always provide one.

Twitter-specific tags

Twitter/X uses Open Graph as a fallback but has its own tags for finer control:

<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="My Page Title">
<meta name="twitter:description" content="Short summary here.">
<meta name="twitter:image" content="https://example.com/og-image.png">

twitter:card has two common values:

summary_large_image — wide image above title (most common)
summary — small square thumbnail to the left of title

Image size and format

Recommended: 1200×630px (Facebook, Twitter, LinkedIn)
Minimum: 600×315px (lower quality but works)
Format: JPEG for photos, PNG for graphics with text
File size: under 1MB for fast load

Twitter has a 5MB hard limit. LinkedIn accepts JPG, PNG, and GIF.

Article-specific tags

For blog posts, add og:type and the article properties:

<meta property="og:type" content="article">
<meta property="article:author" content="https://example.com/about">
<meta property="article:published_time" content="2026-06-12T10:00:00Z">

For most pages (landing pages, tools, product pages), og:type should be website.

Testing your tags

After deploying your OG tags, validate them with:

Facebook: developers.facebook.com/tools/debug/
Twitter/X: cards-dev.twitter.com/validator
LinkedIn: linkedin.com/post-inspector/

These tools show exactly what the card looks like and flag any missing required tags.

Common mistakes

Relative URLs for og:image: always use absolute URLs including https://
Missing og:url: without this, some platforms generate duplicate entries in their cache
Title too long: over 60 chars gets truncated with "…" in most platforms
No image: guaranteed poor-looking share — provide one even if it's just a branded default

Tools

Rather than writing tags from scratch, use a generator to fill in the fields and see a live preview before deploying. The OG Meta Tag Generator at SnappyTools lets you enter your title, description, image URL, and page URL, then shows you what the Twitter card, Facebook card, and LinkedIn card will look like — all in the browser, no URL required.

CSS box-shadow: The Complete Guide to Multi-Layer Shadows

Snappy Tools — Fri, 12 Jun 2026 10:14:49 +0000

The box-shadow property is one of the most underused tools in CSS. Most developers use it for a single subtle drop shadow and stop there — but the full syntax supports layered shadows, inset effects, and colour-based glows that can replace entire images.

This guide covers everything from the basic syntax to advanced multi-layer techniques.

The full syntax

box-shadow: [inset] offset-x offset-y [blur-radius] [spread-radius] color;

Each part:

offset-x — horizontal distance. Positive = right, negative = left.
offset-y — vertical distance. Positive = down, negative = up.
blur-radius — how soft the edge is. 0 = crisp edge, 20px = soft fade. Cannot be negative.
spread-radius — expands (+) or contracts (-) the shadow beyond the element size.
color — usually rgba() so you can control opacity.
inset — optional keyword that puts the shadow inside the element.

Why rgba() for colour?

Most shadow colours are variations of black with opacity. rgba(0, 0, 0, 0.12) gives you black at 12% opacity — the element behind shows through, making the shadow look natural regardless of background colour.

/* Avoid this — opaque black shadow looks fake */
box-shadow: 0 4px 8px #000000;

/* Do this — transparent shadow works on any background */
box-shadow: 0 4px 8px rgba(0, 0, 0, 0.12);

Multiple shadows: the real power

Separate shadows with commas. The first shadow is drawn on top (closest to the element):

.card {
  box-shadow:
    0 1px 3px rgba(0, 0, 0, 0.12),  /* tight shadow for sharpness */
    0 4px 16px rgba(0, 0, 0, 0.08); /* wide shadow for ambient depth */
}

This two-layer pattern is the basis of Material Design's elevation system. Each layer doubles in size while halving in opacity — the result looks like physically accurate depth.

Inset shadows

The inset keyword flips the shadow inside the element. This is perfect for:

Buttons in their active/pressed state
Input fields with a focus ring
Recessed UI surfaces

/* Pressed button effect */
.btn:active {
  box-shadow: inset 0 2px 4px rgba(0, 0, 0, 0.2);
}

/* Input focus ring */
input:focus {
  box-shadow: 0 0 0 3px rgba(66, 153, 225, 0.5);
}

box-shadow as a border

box-shadow: 0 0 0 2px #2f855a creates a 2px ring identical to a border — but without affecting layout. Unlike outline, it respects border-radius exactly.

Useful for stacking multiple rings:

.card:focus {
  box-shadow:
    0 0 0 2px white,         /* inner white gap */
    0 0 0 4px #2f855a;       /* outer green ring */
}

Glow effects

Zero offset + large blur + saturated colour = glow:

.btn-primary {
  box-shadow:
    0 0 12px rgba(47, 133, 90, 0.5),
    0 0 32px rgba(47, 133, 90, 0.2);
}

Common preset values

Effect	CSS
Soft card	`0 2px 8px rgba(0,0,0,0.08)`
Material card	`0 1px 3px rgba(0,0,0,0.12), 0 2px 4px rgba(0,0,0,0.08)`
Floating modal	`0 8px 24px rgba(0,0,0,0.14), 0 16px 48px rgba(0,0,0,0.08)`
Focus ring	`0 0 0 3px rgba(66,153,225,0.5)`
Pressed inset	`inset 0 2px 6px rgba(0,0,0,0.2)`

Performance note

box-shadow triggers repaint, not reflow. For static use it is fast — most GPUs handle it without any measurable impact. For animated shadows, add will-change: box-shadow or animate via transform + a static shadow on a pseudo-element for smoother 60fps results.

If you want to build shadows visually without writing code, try the CSS Box Shadow Generator — it gives you sliders for every parameter, a live preview card, 5 presets, and copies the complete CSS with one click.

Why Formatted SQL Is Worth the Extra Keystrokes

Snappy Tools — Thu, 11 Jun 2026 10:15:11 +0000

Unformatted SQL is a maintenance hazard. A single query stretching across 300 characters with no line breaks is hard to read in a code review, nearly impossible to debug in a log file, and a nightmare to modify six months later.

Formatting SQL costs nothing and saves significant time. Here's why it matters and what consistent formatting looks like.

What "Formatted SQL" Actually Means

Formatted SQL doesn't mean anything fancy — it's just consistent whitespace, capitalisation, and alignment that makes the structure of a query visible at a glance.

Before:

select u.id,u.email,o.total,o.created_at from users u left join orders o on u.id=o.user_id where u.created_at>'2024-01-01' and o.status='completed' order by o.created_at desc limit 100

After:

SELECT
  u.id,
  u.email,
  o.total,
  o.created_at
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
WHERE u.created_at > '2024-01-01'
  AND o.status = 'completed'
ORDER BY o.created_at DESC
LIMIT 100;

The query is identical — the database doesn't care about whitespace. But the second version makes the joins, conditions, and selected columns immediately scannable.

The Code Review Argument

SQL in code reviews is often the most poorly reviewed part of a pull request. Reviewers skim past a wall of unformatted SQL because parsing its structure mentally is too much cognitive work. Formatted SQL gets reviewed properly because:

You can see at a glance which tables are joined and how
You can spot missing index conditions in the WHERE clause
You can identify whether SELECT * is being used (it shouldn't be)
You can check that joins have explicit conditions on the right columns

A reviewer who can read your SQL quickly is more likely to catch bugs — a suboptimal join condition, a missing NULL check, a Cartesian product hiding in a FROM clause.

Capitalisation Conventions

There are two camps:

UPPERCASE keywords — SELECT, FROM, WHERE, JOIN. The traditional SQL style, still the most common in professional environments and documentation. Makes keywords visually distinct from table/column names.

lowercase keywords — select, from, where, join. Preferred by some modern teams, particularly those writing SQL inside application code (Python SQLAlchemy, JavaScript knex.js) where all-caps feels like shouting.

Pick one and stick to it. The worst option is inconsistency — some queries in uppercase, some in lowercase, mixed within the same file.

Indentation Rules That Actually Help

The goal of SQL indentation is to make the logical structure of the query visible:

-- Main clauses at the left margin
SELECT
  column1,           -- Selected columns indented one level
  column2,
  column3
FROM primary_table
LEFT JOIN secondary_table
  ON primary_table.id = secondary_table.fk_id   -- JOIN conditions indented
WHERE condition1 = 'value'
  AND condition2 > 0                             -- AND/OR conditions aligned
  AND (
    sub_condition1 = 1                           -- Grouped conditions indented further
    OR sub_condition2 = 2
  )
ORDER BY column1 DESC;

The structure tells you: what am I selecting, from where, joined to what, filtered how, sorted how. You shouldn't need to read every word to understand the shape of the query.

Common Formatting Mistakes

Putting everything on one line. The database doesn't care, but your future self will hate you for it.

Mixing alignment styles. If you indent JOIN conditions, indent all JOIN conditions. Inconsistency in the same query is more confusing than no indentation at all.

No spaces around operators. WHERE id=5 is harder to read than WHERE id = 5. Always space around =, >, <, !=, LIKE.

Not aliasing tables. FROM very_long_table_name JOIN another_long_table_name ON very_long_table_name.id = another_long_table_name.fk is hard to read. Use aliases: FROM orders o JOIN users u ON o.user_id = u.id.

Forgetting the semicolon. In multi-statement scripts, missing semicolons cause silent failures. Get in the habit.

Formatting Tools

You don't have to format SQL by hand. Most SQL IDEs (DataGrip, DBeaver, VS Code with SQLTools) have built-in formatters. For quick formatting of a query you've copied from a log or a colleague's message, the SQL Formatter & Beautifier at SnappyTools handles MySQL, PostgreSQL, and Transact-SQL in the browser — paste your query, click Format, copy the result.

Useful for one-off formatting without leaving your current context.

A Note on Dialects

SQL syntax varies between databases. Standard formatting rules apply universally, but some syntax is dialect-specific:

MySQL: backtick quoting for identifiers `table_name`
PostgreSQL: double-quote identifiers "table_name", strong adherence to SQL standard
Transact-SQL (SQL Server): bracket quoting [table_name], TOP instead of LIMIT

If you're writing SQL that will run on multiple databases, stick to standard SQL where possible and make the dialect explicit in comments or filenames.

The Bottom Line

Formatted SQL is professional SQL. It signals that you thought about the query carefully enough to make it readable, which is a reliable indicator that you also thought about whether it's correct and performant.

The next time you're about to paste a single-line query into a code review, spend 30 seconds formatting it first. Your reviewers will thank you — and your future self will too.

YAML vs JSON: When to Use Each (and When They're Interchangeable)

Snappy Tools — Thu, 11 Jun 2026 10:11:21 +0000

YAML and JSON represent the same data structures. Both support strings, numbers, booleans, arrays, and nested objects. Both are widely used for configuration and data interchange. So why do both exist, and when should you choose one over the other?

What's the Difference?

At a structural level, YAML is a superset of JSON — valid JSON is valid YAML. But in practice, YAML's syntax is designed for human readability while JSON's is designed for machine parsing.

JSON:

{
  "name": "SnappyTools",
  "version": "1.0",
  "features": ["fast", "free", "no-signup"],
  "config": {
    "maxRetries": 3,
    "timeout": 30
  }
}

The same data in YAML:

name: SnappyTools
version: "1.0"
features:
  - fast
  - free
  - no-signup
config:
  maxRetries: 3
  timeout: 30

The YAML version is shorter and has no curly braces, no commas, and no quotes unless necessary. For configuration files that humans edit frequently, this matters.

When to Use JSON

APIs and HTTP responses — JSON is the standard for REST APIs. All HTTP clients handle it natively. It's faster to parse than YAML and has a simpler, unambiguous spec.

Data interchange between systems — JSON is the lowest common denominator. Every language has a fast, well-tested JSON parser. YAML parsers are more complex and vary in behaviour between implementations (more on this below).

When you don't control both ends — If you're sending data to an external service, use JSON. YAML's flexibility (implicit type coercion, aliases, multiple document support) can cause unexpected behaviour when parsed by a library you didn't configure.

Structured data files where humans won't edit them — package-lock.json, composer.lock, database exports: these are machine-written and machine-read. JSON is the right choice.

When to Use YAML

Configuration files — Kubernetes manifests, Docker Compose, GitHub Actions workflows, Ansible playbooks, CI/CD configs. These are written once and edited frequently by humans. YAML's clean syntax reduces friction.

Multi-line strings — YAML handles multi-line strings elegantly with block scalars. This is painful in JSON.

# YAML block scalar — no escaping needed
description: |
  This is a long description.
  It spans multiple lines.
  No escape sequences needed.

In JSON, the same thing requires \n escape sequences and double quotes.

Comments — YAML supports comments (#). JSON does not. For configuration files, being able to explain why a setting exists is invaluable. This alone makes YAML preferred for config files.

Hierarchical configuration — Deep nesting is more readable in YAML than in deeply-nested JSON objects with closing braces on every line.

YAML Gotchas to Know

YAML's flexibility creates some notorious pitfalls:

The Norway Problem — YAML 1.1 (still used by many parsers) interprets bare NO, N, Off, False as boolean false. This means country codes like NO (Norway) get silently converted to false. YAML 1.2 fixed this, but not all parsers have updated.

Implicit type coercion — version: 1.0 in YAML becomes a float, version: "1.0" stays a string. port: 8080 becomes an integer. This is convenient but can surprise you when your port number becomes an integer in a context expecting a string.

Tabs vs spaces — YAML forbids tabs for indentation. Python developers familiar with spaces-only indentation are used to this, but it trips up others.

String ambiguity — true, yes, on are all booleans in YAML 1.1. To be safe with values that look like keywords, quote them.

Converting Between the Two

If you're working with a tool that outputs JSON but your config expects YAML (or vice versa), you need a converter. The YAML ↔ JSON Converter at SnappyTools handles both directions instantly in the browser — paste JSON to get YAML, paste YAML to get JSON. Useful when translating Kubernetes examples to Docker Compose format, or converting API responses to config file format.

Quick Decision Guide

Situation	Use
REST API response	JSON
CI/CD config (GitHub Actions, CircleCI)	YAML
Kubernetes manifest	YAML
npm/package.json	JSON
Docker Compose	YAML
Database export/import	JSON
Ansible playbook	YAML
OpenAPI / Swagger spec	Either (JSON more common in generated code)
Human-edited config file	YAML (comments + readability)
Machine-generated data file	JSON (simpler parser, less ambiguity)

The general rule: YAML for humans writing configuration, JSON for machines exchanging data.