DEV Community: Snappy Tools

Hash Functions Explained: MD5, SHA-1, SHA-256, and When to Use Each

Snappy Tools — Sun, 07 Jun 2026 10:13:58 +0000

Hash functions are one of those foundational computing concepts that show up everywhere — file integrity checks, password storage, digital signatures, API authentication, blockchain — but the choice of which hash to use is often made without understanding what actually differs between them.

Let me explain the practical differences clearly.

What a Hash Function Does

A hash function takes an input of any length and returns a fixed-length output (the "hash" or "digest"). The key properties:

Deterministic — the same input always produces the same output
One-way — you cannot reverse the hash to recover the original input
Avalanche effect — changing one character in the input completely changes the output
Collision resistant — two different inputs should not produce the same hash (though collisions are mathematically possible)

The output length and collision resistance are what differ between algorithms.

The Main Algorithms

MD5 (128-bit output, 32 hex characters)

MD5 produces a 128-bit digest, displayed as 32 hex characters:

md5("hello") = 5d41402abc4b2a76b9719d911017c592

Status: Cryptographically broken. Collisions (two different inputs with the same hash) can be generated in seconds. MD5 is no longer suitable for any security-sensitive use case.

Still used for: Non-security checksums — verifying a file download wasn't corrupted in transit (corruption is accidental, not adversarial). Some legacy systems and database deduplication where collision attacks are not a concern.

Never use for: Password hashing, digital signatures, certificate fingerprinting, or any context where an attacker could craft a collision.

SHA-1 (160-bit output, 40 hex characters)

sha1("hello") = aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d

Status: Deprecated. Google demonstrated a practical SHA-1 collision attack in 2017 ("SHAttered"). Most certificate authorities stopped issuing SHA-1 certificates years ago, and major browsers no longer accept them.

Still used for: Git commit hashes (Git uses SHA-1 internally for object IDs — collision resistance for Git's use case is sufficient but Git is slowly migrating to SHA-256). Legacy systems.

Never use for: TLS certificates, code signing, password hashing, or anything security-critical.

SHA-256 (256-bit output, 64 hex characters)

sha256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Status: Current standard. Use this for most things.

SHA-256 is part of the SHA-2 family and has no known practical vulnerabilities. It's used in:

TLS certificates (HTTPS)
Code signing
JWT signatures (HS256, RS256)
Bitcoin blockchain
HMAC authentication (HMAC-SHA256)
File integrity verification

When to use it: Any time you need a secure cryptographic hash for production use and don't have a specific reason to choose otherwise.

SHA-512 (512-bit output, 128 hex characters)

SHA-512 produces a longer digest and is slightly faster than SHA-256 on 64-bit processors for large inputs, due to its 64-bit word operations. The practical difference in security is negligible for most applications — both are currently unbroken.

Use when: You need a longer digest for protocol compatibility, or you're hashing very large files and can benchmark a performance difference.

SHA-3 (variable output)

SHA-3 (Keccak) is NIST's third-generation hash standard, with a fundamentally different internal structure from SHA-2. It's not faster than SHA-256 in most cases, but its different construction provides defence-in-depth if a theoretical attack on SHA-2's Merkle–Damgård structure were discovered.

Use when: Your threat model specifically requires defence against SHA-2 structural attacks, or a protocol requires SHA-3.

What Not to Use for Password Hashing

None of the above algorithms — including SHA-256 — should be used directly for storing passwords. They're all too fast.

An attacker with a GPU can compute billions of SHA-256 hashes per second, making dictionary and brute-force attacks trivial against a database of hashed passwords.

Use purpose-built password hashing algorithms instead:

bcrypt — deliberately slow, work factor adjustable
Argon2 — NIST recommended, resistant to GPU attacks, won the Password Hashing Competition
scrypt — memory-hard, makes GPU attacks expensive

These algorithms are specifically designed to be slow and computationally expensive, so brute-forcing a leaked password database takes years rather than hours.

Practical Verification Example

When you download software from the internet, many sites provide a SHA-256 hash of the file. After downloading, you verify it locally:

# Linux / macOS
sha256sum downloaded-file.zip

# macOS alternative
shasum -a 256 downloaded-file.zip

# Windows PowerShell
Get-FileHash downloaded-file.zip -Algorithm SHA256

If the output matches the hash on the download page, the file arrived intact and unmodified.

Quick Reference

Algorithm	Output Length	Security Status	Use For
MD5	32 hex chars	Broken	Non-security checksums only
SHA-1	40 hex chars	Deprecated	Legacy only, avoid
SHA-256	64 hex chars	Secure	General purpose — use this
SHA-512	128 hex chars	Secure	Large files, protocol-specific
SHA-3	Variable	Secure	Defence-in-depth, protocol-specific

Need to generate or verify a hash in the browser? The Hash Generator supports MD5, SHA-1, SHA-256, SHA-384, and SHA-512 — runs entirely client-side, your input never leaves the browser. Useful for quick checksums and learning how different algorithms handle the same input.

Keyword Density in 2026: What the Numbers Actually Mean for SEO

Snappy Tools — Sun, 07 Jun 2026 10:11:36 +0000

Keyword density is one of those SEO concepts that's been declared dead, resurrected, and oversimplified dozens of times. The truth is somewhere more nuanced: density still matters — but not in the "hit 1–2% or Google won't rank you" way it was presented a decade ago.

Here's what the numbers actually mean in practice.

The Formula (and Why It's Just a Starting Point)

Keyword density is calculated as:

Keyword Density (%) = (Keyword Count ÷ Total Word Count) × 100

A 1,000-word article with the keyword "keyword density" appearing 12 times has a density of 1.2%.

That number is useful as a diagnostic, not a target. It tells you whether a keyword is underused, appropriately used, or overused relative to the length of the text. What it can't tell you is whether Google will rank your page — that depends on relevance, authority, user intent, and dozens of other signals.

The Ranges and What They Signal

Density	Classification	What to do
0%	Missing	Add the keyword naturally — at minimum in the title, intro, and a heading
0.1–0.5%	Very low	Fine for secondary keywords; may be too thin for a primary topic
0.5–1%	Low-normal	Good for supporting keywords and related terms
1–2%	Target range	Natural, readable use of a primary keyword for most content types
2–3%	High but acceptable	Common in shorter pieces where the keyword appears in headings and code
3–5%	Borderline	Check if the text reads naturally; reduce if it feels forced
5%+	Over-optimised	Likely keyword stuffing — replace repetitions with synonyms

These ranges describe typical patterns in well-optimised content. They're not thresholds that trigger rankings or penalties.

What Google Actually Uses

Google moved away from keyword density as a primary ranking signal years ago. The current approach is more sophisticated:

TF-IDF (Term Frequency–Inverse Document Frequency) normalises keyword frequency across the corpus — a word that appears everywhere is less meaningful than a word specific to your page. Google doesn't publish its TF-IDF implementation, but the principle guides how keyword importance is weighted.

Semantic relevance matters more than exact match. If you're writing about "coffee brewing methods", mentioning "pour over", "French press", "grind size", and "water temperature" signals topical coverage — even if your exact-match keyword count is lower than a competitor's.

User intent is the frame that context must fit. A page targeting "how to brew coffee" needs step-by-step instructions; a page targeting "best coffee brewing equipment" needs product comparison. Forcing a high keyword density without matching user intent won't work.

Where Density Still Matters Directly

Despite the nuance above, there are three scenarios where density analysis remains directly useful:

1. Detecting keyword stuffing before publishing. Running your draft through a density checker catches accidental over-optimisation — especially in short articles where a technical term might appear in every paragraph without you noticing.

2. Diagnosing thin content. If your primary keyword appears only once in a 2,000-word article, you probably haven't covered the topic with enough depth. Density below 0.3% on a primary keyword often indicates the article has drifted from its intended focus.

3. Checking multi-word phrases. A bigram like "keyword density" might appear only twice (0.2%), while the individual words "keyword" and "density" each appear 15+ times. The phrase-level density check reveals whether you're targeting a specific phrase or just related individual words.

The "How Many Times" Question

People ask: "How many times should my keyword appear in a 1,000-word article?"

If you want a number: 8–15 times for a primary keyword in a 1,000-word article puts you in the 0.8–1.5% range. That's a safe, readable zone for most content types.

But the honest answer is: write naturally, check density afterward, and adjust if the number is wildly out of range. Inserting a keyword exactly 12 times because some guide said so produces awkward prose that users abandon early — which sends a stronger negative signal than keyword density ever could.

Phrases, Not Just Words

Most keyword density tools count single words by default. But your actual keyword target might be a two-word or three-word phrase.

"Keyword density" and "keyword density checker" are different targets. A density check on the phrase "keyword density checker" will show a much lower number than checking "keyword density" alone — and that's the right number to look at when your page is targeting the three-word query.

When checking density for phrases, always verify:

How many times does the exact phrase appear?
How many times do the component words appear independently?

Both numbers are useful. A high individual-word density with low phrase density might mean you're covering the topic broadly but not targeting the specific query clearly enough.

Tools for Checking Density

Yoast SEO (WordPress) checks a single focus keyphrase you specify and gives a pass/fail indicator. Useful for quick checks during writing but limited to one keyword at a time.

Semrush SEO Writing Assistant shows density, readability, and originality in one panel. Requires a subscription.

Free browser tools like this keyword density checker analyse all word frequencies at once — useful for discovering which terms dominate your text before you decide what to optimise for. No account, no word limit, runs entirely in the browser.

The Practical Workflow

Write your content without thinking about density — focus on covering the topic thoroughly.
Paste the draft into a density checker and scan the results.
If your primary keyword is below 0.5%: add a few natural mentions in headings and key paragraphs.
If your primary keyword is above 3%: read the flagged sentences aloud. Replace forced repetitions with synonyms or restructure the sentence.
Check phrase-level density for your target two- or three-word query.
Done. Move on.

Keyword density is a sanity check, not a score to maximise.

URL Encoding Explained: %20, + Signs, and the encodeURIComponent vs encodeURI Confusion

Snappy Tools — Sun, 07 Jun 2026 10:11:35 +0000

URL encoding trips up developers more often than it should. Not because it's complicated — it isn't — but because there are two different standards, multiple languages implement them slightly differently, and the difference between %20 and + for a space has caused real production bugs.

Let me break it down clearly.

Why URLs Need Encoding

HTTP URLs can only safely contain a subset of ASCII characters: letters, digits, and a handful of symbols (-._~:/?#[]@!$&'()*+,;=). Everything else — spaces, accented characters, &, =, #, and non-ASCII text — must be percent-encoded.

Percent-encoding replaces the unsafe character with % followed by the character's UTF-8 byte value in hexadecimal:

Space → %20
& → %26
= → %3D
é → %C3%A9 (two bytes in UTF-8)

Simple enough. The confusion starts when you need to choose which kind of encoding to apply.

encodeURIComponent vs encodeURI: The Core Distinction

JavaScript gives you two built-in functions, and mixing them up is the #1 URL encoding mistake:

encodeURIComponent(value) encodes everything except: A-Z a-z 0-9 - _ . ! ~ * ' ( )

That includes /, ?, =, &, #, @, and : — all URL structural characters.

encodeURI(url) encodes everything except URL structural characters: : / ? # [ ] @ ! $ & ' ( ) * + , ; =

The rule

Use encodeURIComponent for individual query parameter values
Use encodeURI for complete URLs where you only want to encode unsafe characters without touching the URL's structure

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

// Wrong — encodeURI doesn't encode & so the parameter breaks
const url2 = `https://example.com/search?q=${encodeURI(query)}`;
// → https://example.com/search?q=coffee%20&%20cake  ← broken!

The %20 vs + Space Confusion

You'll see both %20 and + used for spaces in URLs. They're not interchangeable:

Form	Standard	Valid In
`%20`	RFC 3986 percent-encoding	All URL contexts
`+`	HTML form encoding (`application/x-www-form-urlencoded`)	Query strings only

%20 is always correct. + is only correct in query strings when the server expects form-data encoding.

This matters when you're encoding a redirect URL as a parameter — a + inside a URL value that gets passed to another server and decoded as RFC 3986 will stay as a literal +, not become a space.

Language Cheat Sheet

JavaScript / Node.js:

// Query parameter values
encodeURIComponent("hello world & more")  // hello%20world%20%26%20more

// Query strings with URLSearchParams
new URLSearchParams({ q: "hello world" }).toString()  // q=hello+world (+ for spaces)

Python:

from urllib.parse import quote, urlencode

quote("hello world & more", safe="")  # hello%20world%20%26%20more
urlencode({"q": "hello world"})        # q=hello+world (form encoding)

Java:

// URLEncoder uses + for spaces — this is form encoding, not RFC 3986
URLEncoder.encode("hello world", StandardCharsets.UTF_8)  // hello+world
// Replace + with %20 if you need RFC 3986:
encoded.replace("+", "%20")

C#:

// Use Uri.EscapeDataString — produces %20 for spaces (RFC 3986)
Uri.EscapeDataString("hello world & more")  // hello%20world%20%26%20more

// Avoid HttpUtility.UrlEncode — uses + for spaces

curl:

curl -G --data-urlencode "q=hello world & more" https://example.com/search

Double-Encoding: The Silent Bug

If you encode an already-encoded string, the % sign itself gets encoded to %25:

%20  (encoded space)
  ↓ encode again
%2520 (which decodes to "%20", not a space)

This is a common source of "double-encoded" URLs that confuse both users and servers. If your encoded string looks like %2520 instead of %20, you have a double-encoding bug.

Fix: always decode before re-encoding if the string might already be encoded.

When a URL Is a Parameter Value

This is the trickiest case — a redirect URL embedded inside another URL:

// Inner URL must be fully encoded so its ? & = / don't break the outer URL
const innerUrl = "https://destination.com/path?key=value&other=data";
const outerUrl = `https://proxy.example.com/redirect?target=${encodeURIComponent(innerUrl)}`;
// → https://proxy.example.com/redirect?target=https%3A%2F%2Fdestination.com%2Fpath%3Fkey%3Dvalue%26other%3Ddata

Only encode the value — not the outer URL's structure.

Quick Reference

Common characters and their encoded forms:

Character	Encoded	Notes
Space	`%20`	`+` only in form data
`&`	`%26`	Query string separator — always encode in values
`=`	`%3D`	Key-value separator — encode in values
`?`	`%3F`	Query start — encode in values
`/`	`%2F`	Path separator — encode in values
`#`	`%23`	Fragment — encode in values
`+`	`%2B`	Encode in values (means space in form encoding)
`%`	`%25`	Encode existing `%` to avoid double-encoding

If you're working with URLs in the browser, there's a free URL Encoder / Decoder that handles both encodeURIComponent and encodeURI modes, plus batch processing for encoding lists of values at once — all client-side, so your URLs never leave the browser.

SQL Formatting Is Not Optional: Here's Why and How

Snappy Tools — Sat, 06 Jun 2026 10:12:32 +0000

Unformatted SQL is a time sink. You spend more time parsing what a query does than understanding whether it's correct. Here's why consistent SQL formatting matters and how to do it without friction.

The Problem With Unformatted SQL

This is real SQL pulled from production code:

SELECT u.id,u.name,o.total,p.name as product FROM users u JOIN orders o ON u.id=o.user_id JOIN order_items oi ON o.id=oi.order_id JOIN products p ON oi.product_id=p.id WHERE u.created_at>'2025-01-01' AND o.status='completed' ORDER BY o.total DESC LIMIT 50

Questions you can't answer at a glance:

How many tables are joined?
What's the filtering condition?
What are we ordering by?

Formatted:

SELECT
  u.id,
  u.name,
  o.total,
  p.name AS product
FROM users u
JOIN orders o ON u.id = o.user_id
JOIN order_items oi ON o.id = oi.order_id
JOIN products p ON oi.product_id = p.id
WHERE
  u.created_at > '2025-01-01'
  AND o.status = 'completed'
ORDER BY o.total DESC
LIMIT 50;

Now you can see the structure immediately: 4 tables, 2 filters, ordering by order total, capped at 50 rows.

Why SQL Formatting Gets Ignored

ORMs hide it. Developers using ActiveRecord, SQLAlchemy, or Hibernate rarely write raw SQL. When they do, it's usually urgent.
One-off queries. SQL in a REPL feels temporary. No one formats throwaway code.
Copy-paste from StackOverflow. The query works; cleaning it up feels unnecessary.
No enforced linter. Most CI pipelines check Python, JavaScript, and CSS formatting. SQL rarely has a linter in the chain.

Formatting Rules That Actually Matter

These 5 rules cover 90% of cases:

1. One clause per line

-- Wrong
SELECT id, name FROM users WHERE active = 1 ORDER BY name;

-- Right
SELECT id, name
FROM users
WHERE active = 1
ORDER BY name;

2. Indent ON conditions

JOIN orders o
  ON u.id = o.user_id

3. Uppercase reserved words

-- Wrong
select * from users where id = 1

-- Right
SELECT * FROM users WHERE id = 1

4. One column per line for wide SELECTs

-- Readable
SELECT
  first_name,
  last_name,
  email,
  created_at
FROM users;

5. Align WHERE conditions

WHERE
  status = 'active'
  AND created_at > NOW() - INTERVAL 30 DAY
  AND role IN ('admin', 'editor')

SQL in Code: Formatting Within String Literals

When SQL lives inside application code, the formatting challenge is harder. Some approaches:

Python (multi-line strings)

query = """
    SELECT
        u.id,
        u.email,
        COUNT(o.id) AS order_count
    FROM users u
    LEFT JOIN orders o ON u.id = o.user_id
    WHERE u.status = 'active'
    GROUP BY u.id, u.email
    HAVING COUNT(o.id) > 0
    ORDER BY order_count DESC
"""

JavaScript (template literals)

const query = `
  SELECT
    user_id,
    SUM(amount) AS total
  FROM transactions
  WHERE created_at >= $1
  GROUP BY user_id
  ORDER BY total DESC
  LIMIT $2
`;

Stored procedures: Keep the SQL in .sql files and import them. Much easier to format, review, and diff than inline strings.

Formatting Dialects

Not all SQL is the same. MySQL, PostgreSQL, SQLite, SQL Server, and Oracle each have dialect differences:

Feature	MySQL	PostgreSQL	SQL Server
String quoting	`'string'` or `"string"`	`'string'`	`'string'`
Identifier quoting	`name`	`"name"`	`[name]`
Limit syntax	`LIMIT 10`	`LIMIT 10`	`TOP 10` or `FETCH FIRST`
Boolean	`TINYINT(1)`	`BOOLEAN`	`BIT`

A formatter that understands dialects will handle these correctly rather than applying a one-size-fits-all style.

When to Minify SQL

Minified SQL (no whitespace) saves a tiny amount of bandwidth in query strings, but the difference is negligible for most applications. Only minify when:

Embedding SQL in environment variables or config files where whitespace causes parsing issues
Logging queries to a monitoring service with character limits
Debugging by comparing two query strings character-by-character

For formatting SQL in the browser — supporting MySQL, PostgreSQL, SQL Server, SQLite, and Spark dialects, with both beautify and minify modes — try the SQL Formatter & Beautifier on SnappyTools. Paste your query, pick your dialect, and get clean formatted output in one click. No signup required.

Base64 Explained: Why Your API Payloads Get 33% Bigger

Snappy Tools — Sat, 06 Jun 2026 10:08:31 +0000

If you've ever embedded an image in a CSS file, read a JWT token, or sent a file via a REST API, you've used Base64. But what is it, why does it make data larger, and when should you use it?

The Core Problem Base64 Solves

Binary data contains every possible byte value (0–255). But many protocols — email (SMTP), HTML, XML, JSON, and older HTTP headers — were designed to carry text only. Some byte values in binary data get misinterpreted as control characters, line breaks, or encoding markers.

Base64 solves this by representing any binary data using only 64 safe characters: A–Z, a–z, 0–9, +, and /. Every system can transmit and store these without corruption.

How Base64 Works

Base64 takes 3 bytes of input and produces 4 characters of output. This is because:

3 bytes = 24 bits
24 bits split into 4 groups of 6 bits each
Each 6-bit group maps to one of 64 characters (2⁶ = 64)

That 3→4 ratio is where the 33% size increase comes from. Every 3 bytes becomes 4 characters, so:

3 bytes input → 4 chars output
100 KB file   → ~133 KB encoded
1 MB image    → ~1.33 MB as Base64

The Padding Signs (= and ==)

If the input isn't a multiple of 3 bytes, Base64 adds padding:

One = means the last group had 2 bytes
Two == means the last group had 1 byte

"hello" (5 bytes) → aGVsbG8=    (one padding char)
"hi"    (2 bytes) → aGk=        (two padding chars? no, one)
"a"     (1 byte)  → YQ==        (two padding chars)

Most decoders handle missing padding gracefully. But if you see a Incorrect padding error in Python, add == to the end before decoding.

Common Uses

1. Data URIs in HTML and CSS

Embed images directly in HTML without extra HTTP requests:

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

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

Good for small icons; avoid for large images (adds page weight and can't be cached separately).

2. JWT Tokens

JWT tokens are three Base64URL-encoded segments separated by dots:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.SflKxwRJSM...

Decode the first two segments to read the header and payload — the last segment is a signature, not Base64-encoded content you should modify.

3. HTTP Basic Auth

Authorization: Basic dXNlcjpwYXNzd29yZA==

This is Base64(username:password). It's not encryption — anyone can decode it. Always use HTTPS.

4. Email Attachments (MIME)

Email protocols are text-only. MIME encodes binary attachments as Base64 and embeds them in the email body. This is why a 1 MB PDF attachment adds ~1.33 MB to the email size.

Base64 vs URL-Safe Base64

Standard Base64 uses + and /, which are reserved characters in URLs. URL-safe Base64 replaces them:

+ → -
/ → _
Padding = is often omitted entirely

Use URL-safe Base64 when embedding encoded data in URL parameters. JWT tokens use URL-safe Base64.

Quick Reference by Language

JavaScript (browser)

// Encode
btoa("hello world")         // "aGVsbG8gd29ybGQ="

// Decode
atob("aGVsbG8gd29ybGQ=")   // "hello world"

// URL-safe (no built-in, add manually)
btoa(str).replace(/\+/g,'-').replace(/\//g,'_').replace(/=/g,'')

Python

import base64

# Standard
base64.b64encode(b"hello world").decode()       # "aGVsbG8gd29ybGQ="
base64.b64decode("aGVsbG8gd29ybGQ=")           # b"hello world"

# URL-safe
base64.urlsafe_b64encode(b"hello world")
base64.urlsafe_b64decode("aGVsbG8gd29ybGQ=")

Java

import java.util.Base64;
import java.nio.charset.StandardCharsets;

// Encode
String encoded = Base64.getEncoder()
    .encodeToString("hello".getBytes(StandardCharsets.UTF_8));

// Decode
byte[] decoded = Base64.getDecoder().decode(encoded);
String result = new String(decoded, StandardCharsets.UTF_8);

// URL-safe
Base64.getUrlEncoder().encodeToString(...)

Command line

# Encode
echo -n "hello" | base64           # aGVsbG8=

# Decode
echo "aGVsbG8=" | base64 -d       # hello

# Encode a file
base64 image.png > image.txt

# Decode a file
base64 -d image.txt > image_decoded.png

What Base64 Is NOT

Not compression — it makes data ~33% larger
Not encryption — anyone can decode it
Not hashing — it's reversible; SHA/MD5 are not

When NOT to Use Base64

Don't encode large binary files and embed them in JSON if you can serve them as file downloads. The size increase and the inability to cache encoded content separately makes Base64 a poor choice for images over 10–20 KB in production.

For quick encode/decode in the browser — including URL-safe mode and batch mode — try the Base64 Encoder & Decoder on SnappyTools. No signup, runs entirely in your browser, no data sent anywhere.

Lorem Ipsum for Developers: Stop Hardcoding Placeholder Text

Snappy Tools — Sat, 06 Jun 2026 10:08:30 +0000

Every developer has done it: opened a new project, needed some placeholder text, and typed "test test test" or copy-pasted the same three sentences from an old project. There's a better way.

What Lorem Ipsum Actually Is

Lorem ipsum is not random gibberish. It's derived from Cicero's philosophical work De Finibus Bonorum et Malorum (45 BC), deliberately scrambled so the words carry no meaning. This is the point — when reviewers read meaningful text, they critique the words. When they see lorem ipsum, they focus on the design.

The classic opening — "Lorem ipsum dolor sit amet..." — has been the default placeholder in print and digital design since Letraset used it in the 1960s, and then Aldus PageMaker made it the default in the 1980s.

The Problem With Static Lorem Ipsum

Most developers copy the same lorem ipsum paragraph everywhere. This creates a few problems:

Layouts optimised for one text length. If your card always shows 75 words of placeholder, you'll never notice it breaks with 20 words or 200 words.

Repetition looks wrong. Stakeholder reviews with 8 identical paragraphs don't represent how the final page will look.

Wrong format for the use case. Sometimes you need HTML <p> tags. Sometimes you need a JSON array for a mock API. Copying plain text and manually wrapping it wastes time.

Generate Lorem Ipsum in Different Formats

Here's what you actually need from a lorem ipsum generator:

<!-- HTML format — paste directly into templates -->
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit...</p>
<p>Sed do eiusmod tempor incididunt ut labore et dolore...</p>

// JSON format — paste into mock API responses or fixtures
[
  "Lorem ipsum dolor sit amet, consectetur adipiscing elit...",
  "Sed do eiusmod tempor incididunt ut labore et dolore..."
]

<!-- Markdown format — paste into .md files or documentation -->
Lorem ipsum dolor sit amet, consectetur adipiscing elit...

Sed do eiusmod tempor incididunt ut labore et dolore...

Quick Shortcuts in Code Editors

VS Code: Type lorem in any HTML file and press Tab. Emmet generates a paragraph automatically. Use lorem*3 to generate 3 paragraphs.

JetBrains IDEs (WebStorm, PhpStorm): Type lorem and press Tab for one sentence. Some versions support lorem100 to generate 100 words.

WordPress Gutenberg: Type /lorem in a new paragraph block and press Enter.

Google Docs: Type =lorem() and press Enter for one paragraph. =lorem(3) gives three paragraphs.

Microsoft Word: Type =lorem(3,5) — 3 paragraphs of 5 sentences each.

Generate Lorem Ipsum in JavaScript

For dynamic placeholder text in React, Vue, or plain JS:

// Using the lorem-ipsum npm package
import { LoremIpsum } from 'lorem-ipsum';

const lorem = new LoremIpsum({
  sentencesPerParagraph: { max: 8, min: 4 },
  wordsPerSentence: { max: 16, min: 4 }
});

// Generate 3 paragraphs
lorem.generateParagraphs(3);

// Generate 5 sentences
lorem.generateSentences(5);

// Generate 50 words
lorem.generateWords(50);

Or with Faker.js (if you're already using it for test data):

import { faker } from '@faker-js/faker';

faker.lorem.paragraphs(3);   // 3 paragraphs
faker.lorem.sentences(5);     // 5 sentences
faker.lorem.words(50);        // 50 words

Generate Lorem Ipsum in Python

import lorem

# One paragraph
print(lorem.paragraph())

# One sentence
print(lorem.sentence())

# Three words
print(lorem.get_word(count=3))

Or with the Faker library:

from faker import Faker
fake = Faker()

# 3 paragraphs
fake.paragraphs(3)

# 5 sentences
fake.sentences(5)

The 100-Word Rule for Testing

When testing a layout, generate three variants:

Short: 10–20 words (button labels, card titles)
Medium: 50–100 words (card descriptions, sidebars)
Long: 200–400 words (article bodies, feature descriptions)

A layout that handles all three is a layout that handles real content. A layout tested with only one length will break in production.

When NOT to Use Lorem Ipsum

Hero sections and headings — real copy reveals whether headlines fit the layout
CTAs and buttons — word count matters for button sizing
High-fidelity prototypes — stakeholders need real content to give useful feedback
SEO pages — lorem ipsum in production signals low-quality content to Google

For quick generation in any format — plain text, HTML, Markdown, or JSON — try the Lorem Ipsum Generator on SnappyTools. It randomises on every copy so repeated pastes produce varied text, and it shows the exact word and character count so you know what you're pasting.

CSS Gradient Animations: Three Techniques That Actually Work

Snappy Tools — Fri, 05 Jun 2026 10:11:27 +0000

Animated gradients are one of those effects that look impressive but have a surprising number of wrong ways to implement them. CSS can't natively interpolate gradient stop colours, which means you can't just write transition: background 0.5s and expect it to work. This post covers three techniques that do work, with the trade-offs for each.

Why transition: background Doesn't Work on Gradients

Browsers can animate background-color smoothly. But background: linear-gradient(...) is not a colour — it's an image value. CSS treats it the same way as background: url(photo.jpg). You can't smoothly transition between two image values, so the browser just jumps from one to the other with no animation.

/* This doesn't animate — it just snaps */
.box {
  background: linear-gradient(135deg, #6c63ff, #f43f8a);
  transition: background 0.5s; /* has no effect on the gradient */
}
.box:hover {
  background: linear-gradient(135deg, #f43f8a, #68d391);
}

Here are three approaches that actually work.

Technique 1: Background-Position Shift (Pure CSS, Most Compatible)

The trick: make the gradient much larger than its container, then animate background-position. The gradient itself doesn't change — it just slides.

.animated-gradient {
  background: linear-gradient(
    270deg,
    #6c63ff, #f43f8a, #68d391, #6c63ff
  );
  background-size: 400% 400%;
  animation: gradientShift 6s ease infinite;
}

@keyframes gradientShift {
  0%   { background-position: 0% 50%; }
  50%  { background-position: 100% 50%; }
  100% { background-position: 0% 50%; }
}

How it works: The gradient is 4× the width of the element. The keyframes shift the visible window from left to right and back. Since the start and end colours match, it loops seamlessly.

Pro: Pure CSS, works everywhere, very smooth.

Con: The animation is a sliding motion, not a colour interpolation — different from a true colour-changing gradient. Also need to duplicate the start colour at the end for seamless looping.

Technique 2: Opacity Crossfade (True Colour Change, No JavaScript)

Layer two gradients using pseudo-elements and crossfade their opacity:

.crossfade-gradient {
  position: relative;
}

.crossfade-gradient::before,
.crossfade-gradient::after {
  content: '';
  position: absolute;
  inset: 0;
  border-radius: inherit;
}

.crossfade-gradient::before {
  background: linear-gradient(135deg, #6c63ff, #f43f8a);
}

.crossfade-gradient::after {
  background: linear-gradient(135deg, #f43f8a, #68d391);
  animation: crossfade 3s ease-in-out infinite alternate;
}

@keyframes crossfade {
  0%   { opacity: 0; }
  100% { opacity: 1; }
}

How it works: One gradient sits on ::before, another on ::after. Fading the ::after opacity from 0 to 1 creates the impression that the gradient is changing colour.

Pro: Looks like a true gradient colour change. No JavaScript.

Con: Uses both pseudo-elements (can't use them for other purposes). Requires position: relative on the parent. You only get two states.

Technique 3: CSS Custom Properties + JavaScript (Most Flexible)

Define the gradient using CSS variables and update them in JavaScript:

.js-gradient {
  background: linear-gradient(
    var(--angle, 135deg),
    var(--color-start, #6c63ff),
    var(--color-end, #f43f8a)
  );
  transition: --angle 0.5s;
}

const el = document.querySelector('.js-gradient');
let hue = 0;

function animate() {
  hue = (hue + 0.5) % 360;
  el.style.setProperty('--color-start', `hsl(${hue}, 70%, 60%)`);
  el.style.setProperty('--color-end', `hsl(${(hue + 120) % 360}, 70%, 60%)`);
  requestAnimationFrame(animate);
}

animate();

How it works: CSS custom properties can be transitioned if registered with @property (Houdini). Even without registration, JavaScript updates them in a requestAnimationFrame loop creating smooth frame-by-frame changes.

Pro: Complete control. You can animate angle, colour, number of stops, or anything. Works with any gradient shape.

Con: Requires JavaScript. For the transition on custom properties to work, you need @property (supported in Chrome and Edge, not Firefox as of 2024).

Animating the Gradient Angle

All three techniques can animate the gradient direction. The simplest approach with pure CSS:

.rotating-gradient {
  background: conic-gradient(
    from var(--angle, 0deg),
    #6c63ff, #f43f8a, #68d391, #6c63ff
  );
  animation: rotate 4s linear infinite;
}

@keyframes rotate {
  to { --angle: 360deg; }
}

For this to work smoothly, register the property:

@property --angle {
  syntax: "<angle>";
  initial-value: 0deg;
  inherits: false;
}

Without @property, the conic rotation will jump rather than animate smoothly.

Performance Note

Gradient animations trigger a repaint on every frame. To keep performance high:

Use will-change: background (or will-change: transform if you're moving the element)
Keep the animated element on its own compositing layer
Prefer opacity/transform changes over background changes where possible — those run on the GPU compositor thread

For UI backgrounds and hero sections, all three techniques are fast enough on modern hardware. For 60+ simultaneous animated gradient elements, consider WebGL.

Quick Reference

Technique	JavaScript?	Looks like	Compatibility
background-size shift	No	Sliding gradient	All browsers
Opacity crossfade	No	Colour change	All browsers
CSS variables + JS	Yes	Anything	Modern browsers
@property + conic	No	Rotating gradient	Chrome/Edge only

For a visual gradient editor that generates the base CSS for any of these techniques, use the free CSS Gradient Generator at SnappyTools — copy the CSS and wrap it in the animation keyframes shown above.

Open Graph Tags Explained: How to Control What Shows When You Share a Link

Snappy Tools — Fri, 05 Jun 2026 10:11:26 +0000

Every time you paste a URL into Slack, Twitter, LinkedIn, or iMessage, those apps fetch metadata from the page and display a rich preview card: title, image, description. That preview is controlled entirely by Open Graph meta tags — a set of HTML <meta> tags that almost every developer adds incorrectly or forgets entirely.

This guide covers what they are, which ones actually matter, and how to add them properly.

What are Open Graph Tags?

Open Graph was created by Facebook in 2010 and is now a web standard. They live in the <head> of your HTML document:

<meta property="og:title" content="Your Page Title" />
<meta property="og:description" content="A short description of the page." />
<meta property="og:image" content="https://example.com/images/og-image.jpg" />
<meta property="og:url" content="https://example.com/your-page/" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Your Site Name" />

When a social platform or messaging app fetches your URL, it reads these tags to build the preview card. Without them, it guesses — usually badly.

The Tags That Actually Matter

og:title

The title displayed in the link preview. It doesn't have to match the page's <title> tag — often a slightly shorter, punchier version works better for social sharing.

Recommended length: 60–70 characters.

og:description

The description shown below the title in the preview card. This is your one sentence to make someone decide whether to click.

Recommended length: 120–155 characters. Don't repeat the title.

og:image

The image shown in the preview card. This has the biggest impact on click-through rate.

Requirements:

Minimum size: 1200×630 pixels (Facebook recommends this for best display across all placements)
Format: JPG or PNG (WebP has inconsistent support)
File size: under 1 MB
Must be an absolute URL (not a relative path)

If you leave this out, platforms will either show nothing or try to grab any image from the page — usually your logo thumbnail or an ad.

og:url

The canonical URL of the page. This prevents duplicate sharing counts when the same content is accessible at multiple URLs (with/without trailing slash, http vs https, etc.).

og:type

Use website for most pages. Use article for blog posts, and then add article-specific tags:

<meta property="og:type" content="article" />
<meta property="article:author" content="https://yoursite.com/about/" />
<meta property="article:published_time" content="2024-05-31T10:00:00Z" />

Twitter Card Tags

Twitter/X uses its own tag format. You need these in addition to OG tags:

<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Your Page Title" />
<meta name="twitter:description" content="Your description." />
<meta name="twitter:image" content="https://example.com/images/og-image.jpg" />

summary_large_image gives you the full-width image preview. summary gives the small thumbnail on the left. For any content with a compelling image, use summary_large_image.

Twitter also accepts the og: versions if twitter: tags are missing, but explicit twitter: tags give you more control.

A Complete Template

Here's the full set to add to every page:

<!-- Open Graph -->
<meta property="og:title" content="Page Title — Site Name" />
<meta property="og:description" content="One sentence describing what's on this page." />
<meta property="og:image" content="https://example.com/og-image.jpg" />
<meta property="og:url" content="https://example.com/this-page/" />
<meta property="og:type" content="website" />
<meta property="og:site_name" content="Site Name" />

<!-- Twitter Card -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Page Title — Site Name" />
<meta name="twitter:description" content="One sentence describing what's on this page." />
<meta name="twitter:image" content="https://example.com/og-image.jpg" />

<!-- Standard meta (still matters for search engines) -->
<meta name="description" content="One sentence describing what's on this page." />

Common Mistakes

1. Forgetting og:image

The single most impactful tag. A link preview without an image gets dramatically fewer clicks.

2. Using a relative path for og:image

/images/og.jpg won't work — it must be a full URL including protocol and domain.

3. Using the same image for every page

This works for the homepage, but article pages should have unique images that hint at the content.

4. og:title over 70 characters

Platforms truncate longer titles, often mid-word.

5. Not validating after deploy

Social platforms cache metadata aggressively. After adding or changing OG tags, validate using Twitter's Card Validator or Facebook's Sharing Debugger to force a cache refresh.

Platform-Specific Notes

LinkedIn: uses og:title, og:description, og:image, og:url — reads og: tags, not twitter: tags
Slack: uses og: tags; will fallback to <title> if og:title is missing
iMessage / WhatsApp: use og: tags for link previews
Discord: uses og: tags; supports og:video for embedded players

Quick Reference

Tag	Required?	Max Length
og:title	Yes	70 chars
og:description	Yes	155 chars
og:image	Yes	— (1200×630px recommended)
og:url	Recommended	—
og:type	Recommended	—
og:site_name	Optional	—
twitter:card	Yes for Twitter	—

For a quick way to generate and preview your OG tags as they'd appear on Twitter, Facebook, and LinkedIn, try the developer tools at SnappyTools — specifically the HTML Entity Encoder for any special characters in your titles and descriptions.

Unix Timestamps Explained: The Developer's Complete Reference

Snappy Tools — Fri, 05 Jun 2026 10:09:15 +0000

Unix timestamps are one of those concepts that every developer encounters constantly but rarely stops to fully understand. They appear in log files, database columns, API responses, and cookie headers. This guide covers everything you need to know — from what they are to language-specific conversion code for every major language.

What is a Unix Timestamp?

A Unix timestamp is a single integer representing the number of seconds elapsed since January 1, 1970, 00:00:00 UTC — known as the Unix epoch.

1717200000  ← this is a Unix timestamp

The epoch date (January 1, 1970) was chosen by Bell Labs engineers when designing Unix. It was simply a convenient, recent reference point that allowed 32-bit integers to cover a useful date range (1901–2038). Modern systems use 64-bit integers, extending the range to hundreds of billions of years.

Seconds vs Milliseconds: The Gotcha

This is the source of more bugs than almost any other timestamp issue:

System	Unit	Example
Unix/POSIX	Seconds	`1717200000` (10 digits)
JavaScript (Date.now())	Milliseconds	`1717200000000` (13 digits)
Java (System.currentTimeMillis())	Milliseconds	`1717200000000`

Rule of thumb: if the number has 13 digits, it's milliseconds. If it has 10 digits, it's seconds. Always check which unit your API or database is using before converting.

Converting a Timestamp to a Date in Every Major Language

JavaScript

// Timestamp → date (JavaScript uses milliseconds)
const date = new Date(1717200000 * 1000);
console.log(date.toISOString()); // "2024-05-31T16:00:00.000Z"
console.log(date.toLocaleString()); // local time

// Current timestamp in seconds
const now = Math.floor(Date.now() / 1000);

Python

import datetime, time

# Timestamp → datetime
dt = datetime.datetime.fromtimestamp(1717200000, tz=datetime.timezone.utc)
print(dt)  # 2024-05-31 16:00:00+00:00

# Current timestamp
print(int(time.time()))

PHP

// Timestamp → formatted date
echo date('Y-m-d H:i:s', 1717200000);  // "2024-05-31 16:00:00" (local)
echo gmdate('Y-m-d H:i:s', 1717200000); // "2024-05-31 16:00:00" (UTC)

// Current timestamp
echo time();

Go

import "time"

t := time.Unix(1717200000, 0).UTC()
fmt.Println(t.Format(time.RFC3339)) // "2024-05-31T16:00:00Z"

// Current timestamp
now := time.Now().Unix()

Ruby

Time.at(1717200000).utc  # => 2024-05-31 16:00:00 UTC
Time.now.to_i             # current timestamp

C# (.NET)

// Timestamp → DateTime
var dt = DateTimeOffset.FromUnixTimeSeconds(1717200000).UtcDateTime;

// Current timestamp
long now = DateTimeOffset.UtcNow.ToUnixTimeSeconds();

Java

Instant instant = Instant.ofEpochSecond(1717200000L);
LocalDateTime dt = LocalDateTime.ofInstant(instant, ZoneOffset.UTC);

// Current timestamp
long now = Instant.now().getEpochSecond();

SQL

-- MySQL: timestamp → datetime
SELECT FROM_UNIXTIME(1717200000);  -- '2024-05-31 16:00:00'

-- PostgreSQL: timestamp → timestamptz
SELECT to_timestamp(1717200000);   -- 2024-05-31 16:00:00+00

-- Current timestamp
SELECT UNIX_TIMESTAMP();  -- MySQL
SELECT EXTRACT(EPOCH FROM NOW());  -- PostgreSQL

Timezone Pitfalls

Unix timestamps are always in UTC — they have no timezone. The confusion happens when you convert them to human-readable dates. Different languages apply the local timezone by default:

# Python: fromtimestamp() uses local time!
datetime.datetime.fromtimestamp(0)    # Local time — dangerous
datetime.datetime.utcfromtimestamp(0) # Naive UTC — better
datetime.datetime.fromtimestamp(0, tz=datetime.timezone.utc)  # Timezone-aware UTC — best

Best practice: always work in UTC and only convert to local time at the display layer.

The Year 2038 Problem

Systems that store Unix timestamps in 32-bit signed integers will overflow at:

2,147,483,647 seconds → 19 January 2038, 03:14:07 UTC

After this, the value wraps to a large negative number, jumping back to 1901. This affects:

Old databases with INT timestamp columns
32-bit embedded systems
Legacy C code using time_t on 32-bit platforms

Modern 64-bit systems are safe until approximately the year 292 billion. If you're writing new code, always store timestamps as BIGINT in databases and 64-bit integer types in code.

What Does Timestamp 0 Mean?

Unix timestamp 0 is the epoch itself: 1970-01-01 00:00:00 UTC.

It's commonly used as a sentinel value meaning "not set" or "no date" in older code. Be careful: some validation code mistakenly treats 0 as invalid when it actually represents a perfectly valid date (January 1, 1970).

Quick Conversion Tool

If you need to convert timestamps without writing code, use the Unix Timestamp Converter — it converts in both directions (timestamp ↔ date), shows the current live timestamp, supports all timezones, and displays relative time. No signup, runs in your browser.

Summary

A Unix timestamp is seconds since 1970-01-01 00:00:00 UTC
JavaScript and Java use milliseconds — always check which unit you're receiving
Convert to local time only at the display layer; store and transmit in UTC
Use 64-bit integers to avoid the Year 2038 problem
Timestamp 0 = the Unix epoch (January 1, 1970), not "invalid"

SQL Formatting: Why It Matters More Than You Think (and How to Do It Right)

Snappy Tools — Thu, 04 Jun 2026 10:05:45 +0000

Nobody disputes that code should be readable. But somehow, SQL gets a pass — compressed into a single line, aliases that are single letters, subqueries nested four levels deep. Here's why that's a mistake and what good SQL formatting actually looks like.

Why SQL Formatting Gets Ignored

A few reasons SQL readability gets neglected:

It "works" either way. The database doesn't care about whitespace.
ORMs hide the SQL. Developers who write Hibernate or SQLAlchemy rarely see raw SQL.
No enforced style guide. Python has PEP 8; SQL has no universally adopted equivalent.
Copy-paste culture. SQL often comes from Stack Overflow or query builders, pre-minified.

The cost shows up in code review ("wait, what does this actually do?"), debugging ("where does this subquery start?"), and onboarding ("who wrote this and can I call them?").

The Core Rules

Keywords in uppercase (or consistently lower)

Pick one and stick to it. Most style guides prefer uppercase keywords because it creates visual hierarchy:

-- Good
SELECT id, name, email
FROM users
WHERE created_at > '2026-01-01'
  AND is_active = true
ORDER BY name ASC;

-- Acceptable (consistent lowercase)
select id, name, email
from users
where created_at > '2026-01-01'
  and is_active = true
order by name asc;

One clause per line

Each major clause (SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY) starts on its own line. Conditions within a clause are indented:

SELECT
    u.id,
    u.name,
    COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o
    ON o.user_id = u.id
WHERE u.is_active = true
    AND u.created_at > '2026-01-01'
GROUP BY u.id, u.name
HAVING COUNT(o.id) > 0
ORDER BY order_count DESC
LIMIT 100;

Alias everything, but name it well

Single-letter aliases (u, o) are fine in short queries. In long queries, use descriptive aliases:

-- Short: fine
SELECT u.id FROM users u JOIN orders o ON o.user_id = u.id;

-- Long: be descriptive
SELECT 
    active_users.id,
    recent_orders.total
FROM users AS active_users
JOIN orders AS recent_orders
    ON recent_orders.user_id = active_users.id;

Subqueries: always indent

SELECT *
FROM (
    SELECT 
        user_id,
        SUM(amount) AS total_spent
    FROM orders
    WHERE status = 'completed'
    GROUP BY user_id
) AS spending
WHERE spending.total_spent > 1000;

CTEs over nested subqueries

Common Table Expressions make complex logic readable:

WITH active_users AS (
    SELECT id, name
    FROM users
    WHERE is_active = true
),
high_spenders AS (
    SELECT user_id, SUM(amount) AS total
    FROM orders
    GROUP BY user_id
    HAVING SUM(amount) > 1000
)
SELECT 
    au.name,
    hs.total
FROM active_users au
JOIN high_spenders hs
    ON hs.user_id = au.id
ORDER BY hs.total DESC;

Formatting Reference

Element	Convention
Keywords	UPPERCASE
Table/column names	lowercase_snake_case
Aliases	AS keyword (explicit)
Commas	End of line (trailing) or start of line (leading) — pick one
Indentation	4 spaces (not tabs)
Line length	Max 100 chars
Semicolons	Always close statements

Tools That Help

Running raw SQL through a formatter before committing it takes about 5 seconds and saves everyone who reads it later 5 minutes.

SnappyTools SQL Formatter & Beautifier formats any SQL query in the browser — supports indentation, keyword casing, and basic dialect-aware formatting. Paste in the ugly version, copy out the clean version.

No account, no upload, runs locally in your browser.

Do you have a team SQL style guide? Or does every developer format differently?

CSS Gradients in 2026: Linear, Radial, and Conic — A Complete Reference

Snappy Tools — Thu, 04 Jun 2026 10:03:53 +0000

CSS gradients are one of those features that look simple until you try to do something precise with them. Here's everything you need to know — syntax, angles, colour stops, and the patterns that show up in real projects.

The Three Types

1. Linear Gradient

background: linear-gradient(direction, color-stop1, color-stop2, ...);

Direction can be:

An angle: 45deg, 135deg
A keyword: to right, to bottom right, to top

/* Left to right */
background: linear-gradient(to right, #2f855a, #68d391);

/* 45° diagonal */
background: linear-gradient(45deg, #667eea, #764ba2);

/* Three stops */
background: linear-gradient(to right, #f6d365, #fda085, #f093fb);

Angle reference:

0deg = bottom to top
90deg = left to right
180deg = top to bottom (same as to bottom)
270deg = right to left

2. Radial Gradient

background: radial-gradient(shape size at position, start-color, end-color);

/* Default: ellipse from center */
background: radial-gradient(circle, #667eea, #764ba2);

/* Circle in top-left corner */
background: radial-gradient(circle at 20% 20%, #ffecd2, #fcb69f);

/* Closest-side sizing */
background: radial-gradient(circle closest-side at 60px 60px, #a8edea, #fed6e3);

Size keywords: closest-side, closest-corner, farthest-side, farthest-corner

3. Conic Gradient

background: conic-gradient(from angle at position, color-stops);

Good for pie charts, colour wheels, and angular patterns:

/* Pie chart: 30% red, 50% blue, 20% green */
background: conic-gradient(red 0% 30%, blue 30% 80%, green 80% 100%);

/* Colour wheel */
background: conic-gradient(red, yellow, lime, aqua, blue, magenta, red);

Colour Stops — The Tricky Part

You can position stops precisely using px, %, or viewport units:

/* Hard stop (no fade) */
background: linear-gradient(to right, 
  #2f855a 50%, 
  #68d391 50%
);

/* Multi-stop with precise positions */
background: linear-gradient(to right,
  #f6d365 0px,
  #fda085 80px,
  #f093fb 200px
);

/* Hint: control the midpoint of the blend */
background: linear-gradient(to right, #2f855a 20%, 40%, #68d391 80%);

Repeating Gradients

/* Stripes */
background: repeating-linear-gradient(
  45deg,
  transparent,
  transparent 10px,
  #2f855a 10px,
  #2f855a 20px
);

/* Rings */
background: repeating-radial-gradient(
  circle at center,
  transparent,
  transparent 20px,
  #667eea 20px,
  #667eea 21px
);

Common Patterns in Real Projects

Use case	Gradient type	Example
Hero background	Linear, 135deg	`#667eea → #764ba2`
Card overlay	Linear, to bottom	`transparent → rgba(0,0,0,0.6)`
Progress bar	Linear, to right	`#2f855a → #68d391`
Radial spotlight	Radial circle	`rgba(255,255,255,0.3) → transparent`
Pie chart	Conic	`red 30%, blue 30%`
Diagonal stripe	Repeating linear	45deg transparent/colour pattern

Browser Support

All three gradient types (linear-gradient, radial-gradient, conic-gradient) are supported in all modern browsers. Conic gradients are the newest — they've been in Chrome since 69, Firefox since 83, and Safari since 12.1.

No prefixes needed in 2026.

Generate Without the Maths

If you'd rather see the result than work out the syntax, the SnappyTools Gradient Generator lets you pick colours, adjust the angle, and copy the CSS directly. Supports linear and radial, with live preview on a real element.

What gradient patterns do you use most? Linear hero overlays, or do you actually use conic gradients in prod?

Readability Scores Explained: Flesch-Kincaid, Gunning Fog, and When They Actually Matter

Snappy Tools — Thu, 04 Jun 2026 10:03:49 +0000

If you've ever pasted text into a readability checker and gotten back a number you didn't know how to interpret, you're not alone. Readability scores are useful — but only if you understand what they're measuring and what they're not.

The Two Most Common Scores

Flesch-Kincaid Reading Ease (0–100 scale)

90–100: Very easy (5th grade)
70–80: Easy (6th grade)
60–70: Standard (7th–8th grade)
50–60: Fairly difficult (high school)
30–50: Difficult (college level)
0–30: Very confusing (professional)

Higher is easier. Most web content should aim for 60–70.

Gunning Fog Index (grade level)

Counts words with 3+ syllables as "complex"
A score of 12 means 12th-grade reading level
Aim for 8–10 for general web audiences
Technical docs can go higher; marketing copy should go lower

What These Scores Actually Measure

Both metrics are based on two things only:

Sentence length (longer = harder)
Word complexity (longer/more syllables = harder)

They do not measure:

Whether your logic is clear
Whether your structure makes sense
Whether the vocabulary is actually appropriate for the topic
Jargon that's short but highly domain-specific

A sentence like "Set NODE_ENV=prod then run npm ci" would score as "very easy" because the words are short — but it's meaningless to someone who doesn't know Node.

When Readability Scores Help

Use them as a signal, not a verdict:

Content marketing and landing pages: Aim for Flesch 65+. Short sentences, short words. If your score is below 50, you're probably writing for yourself, not your reader.

Technical documentation: Aim for Flesch 50–65. You can't avoid technical terms, but you can keep surrounding sentences short. Fog Index 10–12 is fine here.

Legal or financial writing: Don't fight the score — add a plain-language summary at the top instead.

Email copy: Flesch 70+ almost always performs better. Remove adjectives. Shorten paragraphs.

Practical Fixes That Actually Work

Problem	Fix
Long sentences	Split at conjunctions (and, but, so, because)
Passive voice	Find "was/were/been + verb" and invert
Noun stacking	"the configuration file update process" → "updating the config"
Abstract nouns	"utilisation" → "use"; "implementation" → "build"
Hedging	Remove "somewhat", "fairly", "quite"

The Real Goal: Cognitive Load

Readability scores are a proxy for cognitive load — the mental effort required to process a sentence. Lower cognitive load means:

The reader can focus on the ideas, not the words
They're less likely to re-read
They finish more of the piece

For web content, that translates directly to: lower bounce rate, more scroll depth, more conversions.

Check Your Content

Paste any text into the SnappyTools Readability Checker to get Flesch-Kincaid, Gunning Fog, reading time, sentence length distribution, and keyword density — all in one pass, no account needed.

The output shows you exactly which sentences are dragging your score down, so you can fix them surgically rather than rewriting everything.

What's the hardest thing you've had to make readable? Drop it in the comments.