# cleanweb.tools — full content index > A curated collection of 100% free utility tools for web developers, UX designers, and marketers. Everything runs in your browser — no uploads, no accounts, no tracking. Homepage: https://cleanweb.tools Tools hub: https://cleanweb.tools/tools Sitemap: https://cleanweb.tools/sitemap.xml --- # Developer Index: https://cleanweb.tools/tools/category/developer ## JSON Formatter & Validator URL: https://cleanweb.tools/tools/json-formatter Tags: json, formatter, validator, api, developer Paste any JSON payload — from a REST API response, a log line, or a config file — and this formatter will pretty-print it with two-space indentation, surface the exact line and column of the first syntax error, and let you minify it again for production use. Everything runs locally in your browser, so responses containing secrets, PII, or production data never leave your machine. Handy when you're debugging a webhook at 2 a.m., diffing two API versions, embedding compact JSON into a shell command, or just making a 4000-character single-line blob human-readable. Trailing commas, unquoted keys, and single-quoted strings are flagged the same way Node's strict parser sees them, so what validates here will validate in your app. ### Features - Format and beautify JSON with proper indentation - Validate JSON syntax and pinpoint errors instantly - Minify JSON for production use - Copy formatted or minified output to clipboard ### How to use 1. Paste your JSON data into the input field 2. Click "Format" to beautify or "Minify" to compress 3. Review validation status and any error messages 4. Copy the result using the copy button ### FAQ **Q: Is my JSON sent to a server?** A: No. Formatting, validation, and minification all run in your browser via the native JSON parser. Nothing is uploaded, logged, or stored on our side, which makes it safe to paste payloads that include API keys, tokens, or customer data. **Q: Why does my JSON say "Unexpected token" when it looks fine?** A: Strict JSON forbids trailing commas, single-quoted strings, unquoted object keys, and JavaScript-style comments. The error position we show is the first character the parser couldn't accept — usually the comma before a closing brace or a key written without double quotes. **Q: Does minifying change the meaning of my JSON?** A: No. Minification only strips insignificant whitespace between tokens. Keys, values, numeric precision, and array order are preserved exactly, so the minified output is byte-for-byte equivalent to the formatted version once both are re-parsed. **Q: Can I format huge JSON files?** A: The formatter handles multi-megabyte payloads fine on a modern laptop, but the browser UI can get sluggish past ~10 MB. For logs or database exports larger than that, prefer a streaming CLI tool like jq. **Q: What's the difference between JSON and JSON5?** A: JSON5 is a superset that adds comments, trailing commas, unquoted keys, and single quotes — the ergonomics of a JS object literal. Most backend parsers don't accept it. Stick to strict JSON for anything leaving your browser, and use JSON5 only inside config files your own code controls. **Q: Why does a floating-point number round-trip differently after I format it?** A: JSON's number type maps to JavaScript's IEEE-754 double, so 0.1 + 0.2 is still 0.30000000000000004. The formatter doesn't introduce drift — it just exposes precision you'd hit anywhere. For money or very large IDs, encode as a string. --- ## CSS Minifier URL: https://cleanweb.tools/tools/css-minifier Tags: css, minify, compress, optimization, performance Strip every byte your browser doesn't need — comments, trailing semicolons, redundant whitespace, and the blank lines that make authored CSS readable but ship overhead. Useful when you're inlining critical CSS into a transactional email, packing styles into a one-file HTML snippet, hand-optimising an above-the-fold block that bypasses your bundler, or just seeing how much weight your stylesheet carries without its indentation. The tool preserves every declaration, selector, and cascade order exactly as authored — the rendered result is byte-for-byte identical to the original, just smaller. You'll see the compression ratio after each run so you can tell at a glance whether a stylesheet is already lean or still has a lot of redundancy. Everything runs locally: we never see your styles, which matters for unreleased product CSS. ### Features - Minify CSS by removing whitespace and comments - Track compression ratio and file size savings - Preserve CSS functionality while reducing size - Copy minified output to clipboard ### How to use 1. Paste your CSS code into the input field 2. Click "Minify" to compress the CSS 3. Review the compression ratio and size savings 4. Copy the minified CSS for production use ### FAQ **Q: Do I still need to minify if my site is served with gzip or Brotli?** A: It still helps, but the gain is smaller. Gzip already compresses repeated whitespace and common tokens well, so minified + gzipped is typically 5–15% smaller than original + gzipped — worth it on critical path CSS, marginal on already-bundled stylesheets. **Q: Will minifying break my CSS?** A: No — minification only removes insignificant whitespace and comments. Selectors, specificity, and cascade order are preserved exactly. The one thing to double-check is that you haven't relied on a comment as a feature flag; once minified, /* keep */ markers are gone. **Q: How is this different from what my build tool does?** A: Webpack, esbuild, and Lightning CSS also minify in production builds. This tool is for the cases where you don't have that pipeline — email templates, one-off HTML files, quick copy-paste into a CMS, or inlining critical CSS into a head tag. **Q: Will minifying a CSS file break source maps?** A: Yes — once whitespace and line breaks are gone, line-and-column references in an old source map point to nonsense. Regenerate the source map from the minification step, or do minification as part of your build pipeline so the map is emitted alongside. **Q: Can I un-minify CSS I've lost the original source for?** A: Yes. Paste it into any formatter and it'll re-indent and add line breaks. You won't get the original comments or variable names back, but the rules, selectors, and specificity round-trip losslessly — minification is deterministic and reversible in that sense. --- ## UUID Generator URL: https://cleanweb.tools/tools/uuid-generator Tags: uuid, guid, unique id, generator, developer Generate one UUID or a batch of a few hundred at once — each produced by the browser's crypto.randomUUID(), so the bytes come from a cryptographically secure random source, not a weak Math.random fallback. UUID v4 gives you 122 bits of entropy, which is enough collision resistance that two independent services can generate IDs without coordinating. Useful when you're seeding a database, writing a migration that needs fixed example IDs, stubbing a mock API, generating idempotency keys for a payment integration, or tagging test events so you can trace them through a pipeline. Every UUID here matches RFC 4122 version 4 exactly — you can feed them directly into Postgres uuid columns, Node crypto APIs, or any library that validates the version nibble. No network call, no rate limit. ### Features - Generate cryptographically random UUID v4 identifiers - Create single or bulk UUIDs at once - Copy individual or all UUIDs to clipboard - Compliant with RFC 4122 standard ### How to use 1. Click "Generate" to create a new UUID 2. Set the quantity for bulk generation 3. Click any UUID to copy it to your clipboard 4. Use the generated UUIDs in your applications ### FAQ **Q: Is UUID v4 actually unique?** A: Not mathematically guaranteed, but practically yes. With 122 random bits, you'd need to generate ~2.7 × 10^18 UUIDs before a collision becomes likely. You will run out of database rows or hit the heat death of the universe first, so treat them as unique in any real application. **Q: Should I use UUID v4 or v7 for database primary keys?** A: v4 is fine for most apps, but v7 is time-ordered, which keeps b-tree indexes tight and makes newly inserted rows cluster together on disk. If you're generating millions of IDs and care about insert performance, prefer v7. For everything else, v4 is the simple default. **Q: Are these IDs safe to expose in URLs?** A: Yes — v4 UUIDs are unguessable and reveal nothing about when or where they were generated, unlike auto-increment integers. That makes them a reasonable choice for share links and public object IDs, though they're not a substitute for authorisation checks. **Q: Why do the UUIDs I generate always start with the same-ish pattern?** A: They don't — but the 13th character is always "4" (the version) and the 17th is always 8, 9, a, or b (the variant). Those are fixed by the RFC, not a weakness in the randomness. Everything else is genuinely random. **Q: What's the performance cost of generating a thousand UUIDs?** A: Negligible. crypto.randomUUID() runs in low microseconds per call, so even 10,000 UUIDs finish before a React render. If you see a slow page, the bottleneck is probably whatever's rendering the list, not the UUID generation itself. **Q: Is crypto.randomUUID the same as what my backend generates?** A: For v4, yes — the bits come from the same kind of CSPRNG (the OS's secure random source). A UUID generated in the browser is indistinguishable from one generated by Node's crypto.randomUUID or Postgres's gen_random_uuid(). Mixing them in one system is safe. ### Variants #### UUID v4 URL: https://cleanweb.tools/tools/uuid-generator/v4 Spec: RFC 4122 UUID version 4 is a 128-bit identifier with 122 bits of pure random data. This generator calls crypto.randomUUID() directly (falling back to crypto.getRandomValues on older browsers), so every byte comes from your operating system's cryptographically secure random source — the same pool TLS keys and password managers draw from. Nothing weaker, no Math.random fallback. Why v4 is the pragmatic default for nearly every use case: the collision probability after generating 2.7 × 10^18 UUIDs is still under one-in-a-billion. You will run out of storage before you run out of v4 space. Unlike auto-increment integers, a v4 UUID leaks nothing about creation order, total row count, or generator identity — safe to expose in URLs, APIs, and share links. Independent services can mint v4 IDs concurrently without coordination, which is why every major distributed system defaults to it. The output format is lowercase, hyphenated, and strictly RFC 4122-compliant: the 13th character is always 4 (the version nibble) and the 17th is always 8, 9, a, or b (the variant marker). Pipes cleanly into Postgres uuid columns (via gen_random_uuid or your app layer), Node.js crypto APIs, .NET Guid parsers, and every UUID library that validates version bits. **Q: When should I use v4 over v7?** A: Use v4 when you need opaque, non-time-ordered IDs — magic links, session tokens, public resource IDs where you don't want to leak creation order. Use v7 when inserting many rows into an indexed column and database insert performance matters. **Q: Is Math.random() good enough for UUID v4?** A: No. Math.random() is a PRNG with limited state and predictable output — not cryptographically secure. An attacker who sees a few of your "UUIDs" can predict the next ones. Always use crypto.randomUUID() or crypto.getRandomValues(), which pull from the OS CSPRNG. **Q: Can two services generate the same v4 UUID?** A: Mathematically possible but astronomically unlikely. With 122 random bits, you'd need to generate ~2.7 × 10^18 UUIDs globally before the birthday paradox pushes collision probability past 50%. Every service can mint IDs without coordinating — that's the whole point. **Q: Does a v4 UUID reveal anything about my system?** A: No — that's its main advantage over sequential integers or UUID v1. v4 contains no timestamp, no MAC address, no generator identity. Perfect for public-facing IDs where you don't want to leak traffic volume, creation patterns, or which server minted the ID. #### UUID v7 URL: https://cleanweb.tools/tools/uuid-generator/v7 Spec: RFC 9562 UUID version 7, ratified in RFC 9562 in 2024, combines a 48-bit Unix millisecond timestamp with 74 bits of random data. The result is an identifier that sorts chronologically, retains collision resistance indistinguishable from v4, and plays well with database indexes. This generator builds every v7 byte-by-byte from a fresh Date.now() and crypto.getRandomValues() call — no dependencies on a library that might lag behind the spec. The big win over v4 is index locality. B-tree indexes love sequential inserts: consecutive rows land on the same hot page, stay in memory, and cost almost nothing to add. Random v4 IDs scatter across the keyspace, and every insert touches a cold page on disk — fine until your table no longer fits in RAM. Benchmarks on Postgres and MySQL routinely show 2–4× insert throughput improvements with v7 once tables exceed cache size. ORMs that generate IDs client-side (Drizzle, Prisma via the cuid/uuid plugin, TypeORM) are where most teams will see the benefit. The format stays RFC-compliant: the 13th character is 7 (the version nibble), the 17th is 8, 9, a, or b (the variant). Because the 48-bit timestamp is big-endian and leads the UUID, lexicographic sort order equals chronological order — useful in logs, audit trails, and event streams where you want to scan recent records without a separate timestamp column. **Q: How is UUID v7 different from ULID?** A: Both encode a Unix-ms timestamp followed by random bytes. ULID uses Crockford Base32 (26 chars, hyphen-free); v7 uses the standard UUID format (36 chars with hyphens). v7 is newer with RFC 9562 behind it; ULIDs have a longer ecosystem but no official IETF spec. **Q: Do I need sub-millisecond precision?** A: Usually no. v7 uses a 48-bit ms-precision timestamp (good until year 10889). Within a single millisecond, the 74 random bits give you ~1.9 × 10^22 possible IDs — collision within a ms is effectively impossible. RFC 9562 optionally allows a sub-ms counter for strict monotonicity under extreme burst writes. **Q: Is UUID v7 supported in my database?** A: Any database that stores UUIDs does — v7 is still 16 bytes. Postgres 17+ has native uuidv7(); earlier versions generate in the app. MySQL, SQLite, MS SQL store v7 as binary(16) or a string without any special handling. No migration needed from v4 except to start writing v7 for new rows. **Q: Can I extract the timestamp from a v7 UUID?** A: Yes — the first 12 hex characters (48 bits) are a big-endian Unix millisecond count. Parse as an integer and pass to new Date(ms). Useful for debugging and event ordering. Don't rely on it for business logic, though — treat the timestamp as a generation detail, not a first-class property of the record. #### UUID v1 URL: https://cleanweb.tools/tools/uuid-generator/v1 Spec: RFC 4122 UUID version 1 encodes a 60-bit Gregorian timestamp — 100-nanosecond intervals since 1582-10-15 UTC — plus a 14-bit clock sequence and a 48-bit node identifier. Originally the node was the network interface's MAC address, which leaked the generating machine. This generator uses a random node ID with the multicast bit set, which RFC 4122 §4.5 explicitly allows as a privacy-preserving substitute for a real MAC. Browsers can't access hardware MACs anyway. v1 is mostly a legacy format today. The timestamp reveals when the UUID was generated (to within 100 ns), which is a privacy problem for public-facing IDs. v7 solves the same sortability problem with a cleaner format, better entropy, and no MAC-derived fields. Use v1 only when interoperating with a system that explicitly requires it: Cassandra's TIMEUUID column (which orders v1s chronologically for range queries), older Java UUIDs emitted by JUG, legacy Windows COM code, and some enterprise messaging systems that embed v1 in wire protocols. The 13th character is always 1 (version nibble), the 17th is 8, 9, a, or b (variant). The timestamp fields are laid out high-bits-last across the first three hyphen-separated groups — an endianness quirk that catches every developer the first time they try to parse a v1 by hand. Output is lowercase and hyphenated per the RFC. **Q: Why does UUID v1 leak information?** A: The timestamp reveals when the UUID was generated (to within 100 ns), and the original node field was the machine's MAC address — identifying the specific computer. Modern browsers and implementations use a random node with the multicast bit set, but the timestamp leak is inherent to v1 and can't be hidden. **Q: Should I use v1 in new projects?** A: No. For time-ordered UUIDs use v7 — same sortability benefit, no timestamp leak, cleaner spec. For random opaque IDs use v4. v1 exists today almost entirely for interoperability with older systems: Cassandra TIMEUUIDs, legacy Java UUID code, old Windows COM registrations. **Q: Does this generator use my real MAC address?** A: No — browsers don't expose hardware MAC addresses for privacy reasons. This generator creates a random 48-bit node with the multicast bit set, which RFC 4122 §4.5 defines as a valid substitute. The resulting UUID is still a standards-compliant v1. **Q: Can I use v1 to recover when a record was created?** A: Yes — parse the timestamp fields out of the UUID and convert to Unix epoch. Some libraries (uuid-tools, Java UUID) expose this directly. Useful for forensics or debugging, but don't rely on it as a primary timestamp column — create a separate created_at field for that. #### Nil UUID URL: https://cleanweb.tools/tools/uuid-generator/nil Spec: RFC 4122 §4.1.7 The nil UUID — 00000000-0000-0000-0000-000000000000 — is the zero value of the UUID type. RFC 4122 §4.1.7 defines it as a special-case identifier guaranteed never to be confused with a generated UUID, because no version of the generation algorithm can produce an all-zero output. Think of it as the UUID equivalent of a null pointer, an empty string, or a zero integer: a sentinel value that fits the shape of the type but carries "no value" semantics. Uses are narrow but real. Use nil as a placeholder in APIs that can't express optional UUID fields — some gRPC-generated code, older ORM schemas that require NOT NULL columns, wire protocols that lack a nullable variant. Use it as a default in database fixtures during testing, or as a "not yet assigned" marker while a migration runs. Use it as the safe output when parsing a UUID from untrusted input fails, rather than throwing or returning undefined. What not to do: store it alongside real UUIDs in a production primary-key column, because querying for the nil value can accidentally match it against NULL-replacement logic and corrupt downstream data. Because the nil UUID has no version or variant bits set (every bit is zero), it fails strict validators that check the 13th and 17th characters. Some libraries accept it as a documented special case; others reject it. Verify your UUID parsing library handles nil the way you expect before you depend on it in production. **Q: Why not just use null for a missing UUID?** A: When your data type is UUID (a Postgres uuid column, a gRPC message field, a Java UUID object), null may not be allowed or may require a separate nullable wrapper. The nil UUID gives you a UUID-shaped sentinel you can store in a NOT NULL column without reaching for a different type. **Q: Is the nil UUID the same across languages?** A: Yes. It's defined as 128 zero bits rendered as 00000000-0000-0000-0000-000000000000. Java, Python, Go, Rust, .NET, Postgres — every mainstream language and database agrees on the format and comparison behaviour. Copy-paste between stacks without any conversion. **Q: Can I generate multiple different nil UUIDs?** A: No — there's only one nil UUID. All nil UUIDs are identical by definition. The generator still lets you copy it because you'll often paste it into many places, but there's no collision to worry about and no randomness involved. #### GUID (Microsoft) URL: https://cleanweb.tools/tools/uuid-generator/guid Spec: RFC 4122 / .NET Guid GUID (Globally Unique Identifier) is Microsoft's name for the same 128-bit identifier the rest of the world calls a UUID. The practical difference is formatting: Microsoft tools and APIs emit GUIDs in uppercase with surrounding braces — {F47AC10B-58CC-4372-A567-0E02B2C3D479} — which is exactly what .NET's Guid.NewGuid().ToString("B") produces and what SQL Server's uniqueidentifier column returns in many default contexts. Under the braces, every GUID this tool generates is a standards-compliant UUID v4 with 122 bits of cryptographic entropy, produced by crypto.randomUUID(). The bytes are identical to what you'd get from Node's crypto.randomUUID() or Postgres's gen_random_uuid() — only the string presentation differs. Paste it into a UUID library expecting lowercase-without-braces and it'll work after a trivial normalization step. Where the braced uppercase form matters: .reg file entries, C# source code, PowerShell scripts, COM interface identifiers (IID_*, CLSID_*), Windows registry keys, ASP.NET routing when the route parser demands a specific format. A historical wrinkle worth knowing: early Microsoft GUIDs used a different byte order (little-endian in the first three fields), so pre-2000 GUID-to-UUID conversions sometimes required byte swapping. Modern code no longer does this — today's GUIDs and UUIDs are binary-compatible. Only the string rendering differs, and that's what this generator handles for you. **Q: Is a GUID the same as a UUID?** A: Yes. "GUID" is Microsoft's name for the same 128-bit identifier. Modern GUIDs are UUIDs (usually v4) formatted in uppercase with braces. Where historical differences existed — byte order, specific version used — they've been reconciled. Today, on-the-wire bytes are identical; only string rendering differs. **Q: Do I always need braces around the GUID?** A: Depends on the consumer. SQL Server's uniqueidentifier accepts both. .NET's Guid.ToString() supports five format specifiers (N, D, B, P, X) that wrap differently. Reg files and COM registrations generally want braces (format B). When in doubt, emit with braces — they're trivial to strip and unambiguous. **Q: What format does .NET Guid.NewGuid() produce by default?** A: Guid.ToString() with no arguments returns lowercase without braces (format D). This tool emits uppercase with braces (format B), which is what .reg files, COM interface registration, and Windows registry entries use. Both are the same GUID; only the 6-char wrapping differs. **Q: Can SQL Server's NEWID() produce the same format?** A: NEWID() returns an uppercase-without-braces GUID, which SQL Server's string functions display as an uppercase hyphenated UUID. Add braces in your application layer if you need format B. Under the bytes, every NEWID() GUID is a v4 UUID — the same as this tool produces. --- ## Regex Tester URL: https://cleanweb.tools/tools/regex-tester Tags: regex, regular expression, pattern, testing, developer Iterate on a regular expression against real sample text and see every match highlighted the instant you change the pattern. Useful when you're cleaning a log file in a hurry, writing an input-validation rule, reaching for a capture group inside sed, or trying to remember whether \d matches just ASCII digits or every Unicode digit class. The tester uses the same ECMAScript regex engine as your JavaScript runtime, with toggles for the common flags — global (g), case-insensitive (i), multiline (m), dotall (s), unicode (u), and sticky (y) — so what matches here will match in your Node.js or browser code. Capture groups are numbered and, if named, called out by name. No server round-trip: paste production-like data without worrying about it being logged, even when that data is full of PII. ### Features - Test regular expressions with real-time matching - See highlighted matches in your test string - Support for common regex flags (global, case-insensitive, multiline) - Instant feedback as you type your pattern ### How to use 1. Enter your regular expression pattern 2. Type or paste a test string to match against 3. Select the regex flags you need 4. View highlighted matches and capture groups ### FAQ **Q: Do JavaScript regexes match the same way as Python or PCRE?** A: Mostly, but not exactly. JS lacks look-behind support in some older engines (fine in modern Chromium/Firefox/Safari), uses \b a little differently with Unicode, and treats \d as ASCII-only unless you pass the u flag. Test against the engine you'll run in production. **Q: Why does my pattern match more than I expected?** A: Regex quantifiers default to greedy — they consume as many characters as possible. Add a ? after the + or * (e.g., .*?) for a lazy match, or anchor the pattern with \b word boundaries. The "highlight every match" view makes over-matching obvious at a glance. **Q: What does the u flag actually do?** A: It switches the engine into Unicode mode: \u{…} escapes become legal, \d and \w stay ASCII (unless you combine with the v flag), surrogate pairs are treated as a single code point, and invalid escapes throw instead of being silently ignored. Turn it on for anything that touches non-ASCII text. **Q: Should I use regex to parse HTML or JSON?** A: No — HTML and JSON are context-free; regex is not. Use a proper parser (DOMParser for HTML, JSON.parse for JSON). Regex is right for flat, line-oriented text: log lines, CSV fields you already know are simple, filename patterns, identifier validation. **Q: What's catastrophic backtracking, and why did it freeze my tab?** A: A pattern like (a+)+ can try every possible split of a string of a's — exponential work. The engine isn't infinite-looping; it's just exploring too many branches. Rewrite the pattern to avoid nested quantifiers (a+ instead of (a+)+) or use a regex linter like safe-regex. **Q: Can I paste secrets into the test string?** A: Yes — the tester is fully client-side. Nothing leaves your browser, no pattern or input is logged. Credentials, tokens, and personal data are safe to paste in while iterating on a pattern. --- ## Password Generator URL: https://cleanweb.tools/tools/password-generator Tags: password, security, generator, random, secure Produce strong passwords using the browser's cryptographically secure random generator (crypto.getRandomValues), not the weak Math.random fallback many ad-hoc generators still rely on. Dial in the length (16+ recommended for anything sensitive), toggle lowercase, uppercase, digits, and symbols, and generate one or a batch of passwords to rotate across several accounts at once. Every password is generated locally; we never see it, we don't log it, we don't transmit it — which matters because password managers are the only safe place for a new credential to land, and a browser tab is a brief stop on the way. Useful when you're creating a new service account, rotating a leaked credential, seeding a dev environment, or handing a fresh password to a teammate through your team's secret-sharing tool. ### Features - Generate cryptographically secure random passwords - Customize password length and character types - Include uppercase, lowercase, numbers, and symbols - Generate multiple passwords at once ### How to use 1. Set your desired password length using the slider 2. Toggle character types (uppercase, lowercase, numbers, symbols) 3. Click "Generate" to create secure passwords 4. Click any password to copy it to your clipboard ### FAQ **Q: Are the passwords really generated in my browser?** A: Yes. The generator calls window.crypto.getRandomValues, which pulls entropy from the operating system's CSPRNG. No password is sent to a server, logged, or even stored in localStorage — reload the page and every value is gone. **Q: How long should my password be?** A: 16 characters with mixed case, digits, and symbols is a sensible floor for web services. 20+ is reasonable for anything important (bank, email, password-manager master). Length matters more than symbol variety — a 20-character lowercase passphrase beats a 10-character "h@Xx0r!" pattern. **Q: Can I trust a random-looking password more than a passphrase?** A: Only if you use a password manager. Humans can't remember Jf$7k!9pQz… which means it ends up written on a sticky note. For accounts you must type manually, a four- or five-word diceware passphrase is both memorable and brute-force-resistant. **Q: Should I reuse the same generator settings for every site?** A: It's fine — what matters is that each site gets a unique password, not that each site uses a different character set. Pick one comfortable setting (e.g., 20 chars with symbols) and generate a fresh password per service, then store them all in a password manager. **Q: Are symbols required to make a password strong?** A: No — length dominates. A 20-character lowercase passphrase has more entropy than a 10-character password with symbols, and it's vastly easier to type on mobile. Symbols mostly help when a site caps length at 12–16 chars; otherwise, add characters, not punctuation. **Q: What do I do if a site rejects a symbol the generator produced?** A: Regenerate without symbols (toggle the symbols option off), or turn off the one specific character class the site bans. Legacy banking sites often forbid <>&. Keep the length as long as they'll allow — 16 plus mixed case and digits is usually enough to pass. ### Variants #### Strong Password URL: https://cleanweb.tools/tools/password-generator/strong A strong password in 2026 means length first, character variety second. This generator produces 16–64 character random passwords drawn from the full ASCII printable alphabet (uppercase, lowercase, digits, and symbols by default), with every character sampled from crypto.getRandomValues — the browser's cryptographically secure PRNG, seeded by your operating system's entropy pool. No Math.random shortcuts that would make the output predictable. What makes a password "strong": entropy, measured in bits. A 16-character password from a 95-character alphabet has ~105 bits of entropy, which is more than any realistic brute-force attack can crack. 20 characters gives 131 bits; 32 gives 210. For reference: a 12-character password is weak enough that GPU farms can crack common variants in days, while a 16-character random password would take billions of years on the same hardware. The length gap matters; the symbol variety matters less than people think. Use strong random passwords only with a password manager. A 20-character random string is unforgettable by design — it exists to be pasted into a password field and forgotten until the manager autofills it next. For accounts you must type by hand (your password manager's master password, device login, some VPNs), use the memorable variant instead. **Q: How long should a strong password be in 2026?** A: 16 characters minimum, 20+ for anything important. GPU-based cracking speed has roughly doubled every two years for 15 years, so old rules ("8 characters is plenty") are obsolete. Length buys far more security than adding symbols: a 20-char lowercase password beats a 10-char password with all ASCII. **Q: Is Math.random good enough for password generation?** A: No. Math.random is a pseudorandom generator with limited internal state; its output is deterministic once a few samples leak. An attacker seeing 3–4 passwords from the same generator can predict the rest. This tool uses crypto.getRandomValues, which pulls from the OS CSPRNG used for TLS keys. **Q: Do I need to memorise a strong random password?** A: No — that's the point. Random strings this long are unforgettable by construction. Store them in a password manager (1Password, Bitwarden, KeePass, Apple Passwords) and autofill. The only password you should memorise is your password-manager master — use a memorable passphrase for that one. **Q: Should I rotate strong passwords regularly?** A: Only after a known breach. NIST dropped mandatory periodic rotation in SP 800-63B because it encourages users to pick weaker, predictable variations (Password1!, Password2!). A 20-char random password that hasn't leaked is strong indefinitely. #### Memorable Passphrase URL: https://cleanweb.tools/tools/password-generator/memorable Memorable passphrases replace random character soup with 4–8 common English words joined by hyphens, ending in two random digits. The words are picked uniformly at random from a ~300-word list using crypto.getRandomValues — the same secure random source behind a strong password generator, just applied to a different alphabet. The result: something like "meadow-thunder-pencil-robot-42" that a human can hold in working memory long enough to type, but an attacker can't brute-force in any realistic time. The security math is better than it looks. With a 300-word list and uniform sampling, each word gives ~8 bits of entropy. A four-word passphrase has ~32 bits plus the trailing digits — about the security of a 6-character random ASCII password, cracked in minutes by a GPU. A five-word passphrase has ~44 bits, which takes months. Six words gets you to ~52 bits, essentially uncrackable by current hardware. For a password-manager master or device login, use at least five words — for anything disposable, four is fine. Why memorable beats random for humans: you actually type it correctly the first time on mobile, you can dictate it verbally (tech support, shared device setup), and you can reconstruct it from memory after a device wipe. The downside is length — a memorable passphrase runs 25–40 characters, which some legacy systems cap. Use strong random passwords with a manager everywhere else; save memorable for the handful of credentials you type by hand. **Q: Is a four-word passphrase strong enough?** A: For most accounts with rate-limiting, yes — four words from a 300-word list give ~32 bits of entropy plus the trailing digits. For your password-manager master, device login, or anything that stores directly as a hash (no rate-limit), use five or six words. The security grows exponentially with word count. **Q: How is this different from Diceware?** A: Diceware uses a specific 7776-word list generated by Arnold Reinhold in 1995 and picks words with physical dice. This tool uses a smaller curated list of 300 common English words picked with crypto.getRandomValues. Fewer words per pick means less entropy per word, so you need a few more words to match Diceware security. **Q: Why are passphrases easier to type on mobile?** A: Autocorrect helps — it recognises and suggests common words after the first couple of letters. Swipe typing works well on recognisable words. Random character passwords disable autocorrect and force precision, which produces far more typos. Passphrases are the only practical option for accounts you log into regularly from a phone. **Q: Should I add my own words to a generated passphrase?** A: No — inserting "personal touches" makes the passphrase guessable by anyone who knows you (pet names, birth years, favourite teams). The whole point of random word selection is no personal information leaks into the password. If you want a memorable anchor, add it as a prefix outside the generated words. #### Random PIN URL: https://cleanweb.tools/tools/password-generator/pin Random PINs are short numeric-only passwords: 4 to 12 digits, each picked uniformly from 0–9 via crypto.getRandomValues with rejection sampling to eliminate modulo bias. They exist where text-entry is awkward or where the destination only accepts digits: phone lock screens, 2FA backup codes, bank card PINs, combination safes, door-entry keypads, voicemail passcodes. The security properties are blunt: 4-digit PIN has 10^4 = 10,000 possible values, brute-forced in seconds without rate-limiting. 6 digits raise the ceiling to 10^6 = one million — which is what most phone lock screens and 2FA apps use because the device-level rate-limit (wiped after 10 wrong attempts) makes brute-force impractical. 8-digit PINs give ~27 bits of entropy; 12 digits give ~40 — still weaker than a short random alphanumeric password, but safe enough when rate-limiting is enforced. A caveat the generator enforces: picked digits are uniformly random, not weighted. Real-world human-chosen PINs are heavily biased (1234, 0000, 1111, birthdays) and attackers know this — a huge study by Nick Berry found 27% of human-chosen 4-digit PINs are in the top 20 values. Every PIN this generator produces is drawn uniformly at random, which means no predictable patterns, no accidental birthdays, and no duplication bias. **Q: Is a 4-digit PIN secure?** A: Only with rate-limiting. 4 digits = 10,000 possible values, brute-forced in seconds on a leaked hash. Phone lock screens use 4-digit PINs safely because the device wipes after 10 failed attempts — that rate-limit is what's keeping your phone secure, not the PIN length. **Q: Should I use 6 or 8 digits for a bank card?** A: 4 or 6 is standard in most markets (Europe uses 4, the US is split between 4 and 6, China uses 6). More digits don't help much at an ATM — the physical card, the daily withdrawal cap, and the bank's fraud model are the real defences. The PIN is just to prove you're the cardholder. **Q: Are the PINs truly random?** A: Yes. Every digit comes from crypto.getRandomValues with rejection sampling to eliminate modulo bias (a subtle flaw where % 10 on certain RNG outputs produces slightly uneven distributions). The result is indistinguishable from physical dice rolls and carries no patterns an attacker could exploit. **Q: Can I use a PIN as a password?** A: No — unrate-limited PINs are trivially brute-forceable. If a website lets you set a "PIN" as your password, use the Strong or Memorable generator instead; PINs belong on devices and accounts with rate-limit protection like phones, SIM cards, 2FA apps, and physical locks. --- ## HTML Entity Encoder URL: https://cleanweb.tools/tools/html-entity-encoder Tags: html, entities, encode, decode, web Encode special characters like <, >, &, and quotes into their HTML entity equivalents for safe display in web pages. Decode HTML entities back to their original characters. ### Features - Convert special characters to HTML entities - Decode HTML entities back to original characters - Handle all standard HTML entity references - Copy converted output to clipboard ### How to use 1. Paste text containing special characters into the input 2. Select "Encode" to convert to HTML entities or "Decode" to reverse 3. View the converted output instantly 4. Copy the result for use in your HTML pages ### FAQ **Q: Which characters actually need encoding?** A: In body text, only < > and &. In attribute values, add " and '. Everything else is legal as its literal character in UTF-8-encoded HTML. Encoding more is harmless but clutters the source — the minimum safe set is five characters. **Q: What's the difference between named and numeric entities?** A: Named entities (&, ©) are easier to read; numeric (&, © or &, ©) work regardless of the parser's entity table. HTML5 defines about 2200 named entities; XML parsers only know five. For cross-context safety, prefer numeric. **Q: Does encoding defend against XSS?** A: Partly. Output-encoding in the right context (HTML body, attribute, URL, CSS, JS) is a core XSS defence, but each context needs the right encoder. HTML-entity-encoding a value destined for a JS string doesn't help — it still gets executed. Use context-aware sanitisers like DOMPurify for full defence. **Q: Why do non-ASCII characters like é or 中 not get encoded?** A: They don't need to be, as long as your page is served as UTF-8 (which it should be). Legacy systems that can't declare a charset still use entities like é, but modern HTML5 documents pass literal Unicode through safely. **Q: Will this break apostrophes inside JSON-in-HTML?** A: The entity ' (or ') is safe inside HTML but not strictly valid JSON — JSON.parse will choke on it. If you're emitting JSON inside an HTML script tag, encode only the three characters that break the script context (< > &) and leave quotes alone. --- ## Hash Generator URL: https://cleanweb.tools/tools/hash-generator Tags: hash, md5, sha, security, crypto Generate cryptographic hashes from text input using various algorithms including MD5, SHA-1, SHA-256, and SHA-512. Useful for verifying data integrity and security applications. ### Features - Generate MD5, SHA-1, SHA-256, and SHA-512 hashes - Hash any text input in real-time - Compare hash outputs across multiple algorithms - Copy hash values to clipboard ### How to use 1. Enter or paste your text into the input field 2. View hash values generated across all algorithms 3. Click any hash value to copy it to your clipboard 4. Use the hashes for data integrity verification ### FAQ **Q: Is MD5 still safe to use?** A: Not for anything that matters. Collision attacks are trivial — you can craft two different inputs with the same MD5 in seconds. Still fine for non-security uses: file deduplication, ETag generation, cache keys. Anywhere an attacker might choose the input, use SHA-256 or better. **Q: Should I use SHA-256 or SHA-512?** A: SHA-256 is the right default for almost every use case — short output, broadly supported, no known weaknesses. SHA-512 has the same security strength and a larger output; prefer it when you want more entropy bits in tokens or if you're on a 64-bit CPU where SHA-512 is actually faster than SHA-256. **Q: How do I hash a password?** A: Not with any of these. Password storage needs a slow function with a per-user salt — argon2id, bcrypt, or scrypt. MD5 and SHA hashes run in nanoseconds, which means a leaked hash database can be brute-forced in hours. Never store plain SHA-hashed passwords. **Q: Do all these hash functions always produce the same length output?** A: Yes — that's the point of a fixed-size hash. MD5: 128 bits (32 hex). SHA-1: 160 bits (40 hex). SHA-256: 256 bits (64 hex). SHA-512: 512 bits (128 hex). Any input from 1 byte to a terabyte produces exactly that many bits of output. **Q: Is my input sent to a server?** A: No — all hashing runs through the SubtleCrypto browser API in your tab. That matters for inputs like API tokens, file contents, or anything sensitive: a hash function applied to a secret is still bound to that secret, and logging either would be a leak. ### Variants #### MD5 Hash URL: https://cleanweb.tools/tools/hash-generator/md5 Spec: RFC 1321 MD5 is a 128-bit hash function designed by Ron Rivest in 1991 and standardised as RFC 1321. It produces a 32-character hexadecimal digest from any input. This generator ships a bundled MD5 implementation that runs in your browser — SubtleCrypto deliberately refuses MD5 because the algorithm is broken for security use, so we include our own RFC 1321-compliant version tested against the official test vectors. What MD5 is still good for: file deduplication (comparing large files by hash rather than byte-by-byte), ETag generation in HTTP caching, cache-busting fingerprints on static assets, and non-adversarial integrity checks where a collision would only happen by accident rather than deliberate attack. Git uses SHA-1 for similar reasons — collisions exist but don't happen in practice unless someone is actively trying to produce one. What MD5 is not good for: password hashing (use argon2id or bcrypt), digital signatures (use SHA-256 or SHA-512), malware detection (attackers can and do craft collisions to evade MD5-based signatures), or anything where an attacker controls the input. Chosen-prefix collisions against MD5 can be computed in seconds on a laptop. The algorithm stays popular for legitimate reasons, but "is this MD5?" and "is this secure?" are two independent questions. **Q: Why doesn't the browser's SubtleCrypto support MD5?** A: MD5 is cryptographically broken — chosen-prefix collisions can be computed in seconds. The browser deliberately refuses to implement it so developers don't accidentally use it for security. This tool ships a bundled MD5 implementation for the legitimate non-security uses that remain. **Q: Is MD5 faster than SHA-256?** A: Yes, noticeably — MD5 is about 2–3x faster on general-purpose CPUs, since the algorithm is simpler and uses a smaller state. For hashing very large files (gigabytes) where the hash is only for deduplication or integrity checking, MD5 remains a reasonable speed-first choice. **Q: Can I use MD5 to check file integrity?** A: Against accidental corruption, yes — if bits flip randomly during transfer, MD5 catches it reliably. Against a deliberate attacker, no — an attacker can craft two files with the same MD5 and swap one for the other. Use SHA-256 for integrity checks where the sender isn't trusted. **Q: Why is MD5 still used if it's broken?** A: Because "broken for security" and "broken for all uses" are different. MD5 is perfect for cache keys, content-addressable storage, fingerprinting non-adversarial inputs, and interoperating with older systems. The ecosystem hasn't replaced it there because nothing is broken about those uses. #### SHA-1 Hash URL: https://cleanweb.tools/tools/hash-generator/sha1 Spec: FIPS 180-4 SHA-1 is a 160-bit cryptographic hash function published by NIST in 1995 (FIPS 180-1). It produces a 40-character hexadecimal digest from any input. This generator computes SHA-1 via your browser's SubtleCrypto API, which still supports SHA-1 despite the algorithm's known weaknesses — unlike MD5, SHA-1 is included because of the large volume of existing code that depends on it. SHA-1 has been cryptographically broken since 2017, when Google and CWI demonstrated the SHAttered attack: two different PDF files producing the same SHA-1 hash, computed for about $110,000 worth of cloud compute. The attack is now affordable to well-resourced adversaries, and newer chosen-prefix variants (SHAmbles, 2020) are cheaper still. Every major TLS certificate authority and code-signing platform has deprecated SHA-1 for new signatures; Git is the largest remaining production use, and even Git is migrating to SHA-256. Legitimate modern uses are narrow: interop with legacy systems that hard-code SHA-1 (older APIs, webhook signatures from GitHub pre-2020), Git object IDs, HMAC-SHA1 in existing code, and computing checksums where collision attacks are out of scope (random duplicate detection, non-adversarial ETags). For new code, use SHA-256 or SHA-512 instead — they're only marginally slower and have no known weaknesses. **Q: Why is SHA-1 still in browsers if it's broken?** A: Because too much legacy code depends on it — Git object IDs, old webhook signatures, pre-2017 TLS certificates, HMAC-SHA1 installations. Removing SHA-1 would break the ecosystem. The browser supports it with warnings instead of refusing, unlike MD5. **Q: Can I still use SHA-1 for HMAC?** A: HMAC-SHA1 is still considered secure today — the HMAC construction is resilient to the collision attacks that broke plain SHA-1. Existing integrations (AWS v4 signing, some webhook signatures) are safe to keep. For new systems, prefer HMAC-SHA256 anyway. **Q: Is SHA-1 faster than SHA-256?** A: Marginally — about 20–30% faster on general-purpose CPUs. On hardware with SHA extensions (modern Intel and ARM cores have dedicated SHA-256 instructions), SHA-256 is often faster in practice. The speed argument for keeping SHA-1 has mostly evaporated. **Q: What is the SHAttered attack?** A: A 2017 demonstration by Google and CWI producing two different PDF files with the same SHA-1 hash, using about $110,000 of cloud compute. It proved SHA-1 collisions are affordable to motivated attackers, triggering the deprecation push across TLS CAs, code-signing, and document-signing. #### SHA-256 Hash URL: https://cleanweb.tools/tools/hash-generator/sha256 Spec: FIPS 180-4 SHA-256 is a 256-bit cryptographic hash function from the SHA-2 family, published by NIST in 2001 (FIPS 180-4). It produces a 64-character hexadecimal digest. This generator computes SHA-256 through your browser's SubtleCrypto API, which on modern CPUs (Intel, AMD, ARM with crypto extensions) uses dedicated hardware instructions — the hash is usually computed faster than the bytes can be read from disk. SHA-256 is the pragmatic default for anything security-sensitive: TLS certificate signing, code-signing certificates, digital signatures, HMAC authentication, Bitcoin and Ethereum addresses, Git object IDs (in SHA-256 mode), Merkle trees, blockchain proofs, and content-addressable storage like IPFS CIDs. No practical collisions have been demonstrated despite 25 years of cryptanalysis, and none are expected before quantum computers become practical — at which point everything downstream of RSA-3072 breaks first anyway. The 256-bit output gives 128-bit collision resistance (birthday bound) and 256-bit preimage resistance — more than enough to never worry about the algorithm breaking in your lifetime. The output is twice the size of MD5 and 1.6× SHA-1, which matters for small data structures but is usually irrelevant. Use SHA-256 as the default; reach for SHA-512 only when you specifically need longer output or run on a 64-bit CPU where SHA-512 is counterintuitively faster. **Q: Is SHA-256 quantum-resistant?** A: Partially. Grover's algorithm halves the effective security of any hash function, so SHA-256 against a quantum attacker gives ~128 bits of preimage resistance instead of 256. That's still secure for decades. More urgent quantum risks are elsewhere — RSA, ECDSA, and Diffie-Hellman break completely. **Q: Is SHA-256 the same as SHA-2?** A: SHA-2 is the family; SHA-256 is one member. The family also includes SHA-224, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. All share the same algorithmic core. SHA-256 is the most widely deployed member because its output size is convenient and its speed is excellent. **Q: Why is SHA-256 slower than MD5?** A: More rounds (64 vs 64, but with more expensive operations), larger internal state (256 bits vs 128), and more complex logical functions. On modern CPUs with hardware SHA extensions, SHA-256 closes the gap or wins — the Intel SHA-NI and ARM SHA extensions only accelerate SHA-2, not MD5. **Q: Can two different inputs produce the same SHA-256?** A: Mathematically yes (pigeonhole), practically no. The birthday bound of 2^128 operations is beyond any conceivable computational resource — if every atom in the universe computed a trillion SHA-256s per second, finding a collision would still take millions of years. Treat outputs as unique. #### SHA-512 Hash URL: https://cleanweb.tools/tools/hash-generator/sha512 Spec: FIPS 180-4 SHA-512 is a 512-bit cryptographic hash function from the SHA-2 family, published alongside SHA-256 in FIPS 180-4. It produces a 128-character hexadecimal digest. This generator computes SHA-512 through your browser's SubtleCrypto API. Unlike SHA-256 — which is optimised for 32-bit word operations — SHA-512 operates on 64-bit words, which means on modern 64-bit CPUs it is often faster than SHA-256 despite producing twice the output size. When to choose SHA-512 over SHA-256: you want a longer random-looking fingerprint (HMAC keys, session tokens derived from hashes, content-addressable IDs where you want the output to be obviously distinguishable from other hash families), you're on a 64-bit-only platform and the speed improvement matters, or you're implementing an interop target that specifies SHA-512 (older RSA-PSS signatures, some RFC-defined protocols, Ed25519 internally uses SHA-512). When to stick with SHA-256: the extra 32 bytes of output take up space you don't need (256-bit collision resistance is already beyond any foreseeable attack), you're on an embedded or 32-bit platform where SHA-256's word size matches the hardware better, or you're matching what your ecosystem expects (most TLS certificates, most blockchain addresses, most HMAC deployments use SHA-256). Both algorithms have the same security margin against classical and quantum attacks — the choice is about output size and CPU-word fit. **Q: Is SHA-512 more secure than SHA-256?** A: Against classical attackers, marginally — both exceed any realistic brute-force threshold. Against quantum attackers (Grover's algorithm), SHA-512 gives 256-bit effective preimage resistance vs SHA-256's 128-bit, which some long-term security specs prefer. In practice, both are fine. **Q: Why is SHA-512 sometimes faster than SHA-256?** A: SHA-512 operates on 64-bit words; SHA-256 operates on 32-bit words. On 64-bit CPUs (every modern server, laptop, phone), SHA-512 processes the same amount of data in fewer operations. Without hardware SHA extensions, SHA-512 typically wins by 20–40% despite producing twice the output. **Q: Can I truncate SHA-512 to get a shorter hash?** A: Yes — SHA-512/256 (FIPS 180-4) is officially SHA-512 truncated to 256 bits using a different IV. You can also just take the first 32 hex characters of a SHA-512 output, which gives 128-bit collision resistance. Both forms are secure; the spec'd truncated variants have a slightly cleaner security proof. **Q: Is SHA-512 used in Bitcoin?** A: No — Bitcoin uses SHA-256 throughout (addresses, proof-of-work, Merkle trees). SHA-512 appears more in cryptographic signatures (Ed25519 internally), BIP-39 seed derivation (via HMAC-SHA-512), and password-based KDFs where the larger internal state helps spread entropy. --- # Designer Index: https://cleanweb.tools/tools/category/designer ## Color Picker & Converter URL: https://cleanweb.tools/tools/color-picker Tags: color, hex, rgb, hsl, palette, design Dial in a colour with a visual picker and instantly see it rendered in every format you're likely to paste somewhere — 3- and 6-digit HEX, RGB, RGBA, HSL, and HSLA. Useful when a designer hands you a Figma palette in HEX but your chart library wants RGB, when you're matching a brand colour pulled from a screenshot, or when you need to nudge an HSL hue to a slightly darker shade without reaching for Photoshop. The picker runs entirely client-side, so unreleased brand colours don't get logged anywhere. Copy any representation to the clipboard with one click, tweak hue, saturation, and lightness independently, and keep a running preview so you can eyeball contrast before committing the change to your stylesheet. ### Features - Pick any color with an interactive color wheel - Convert between HEX, RGB, and HSL formats - Copy color codes to clipboard in any format - Real-time preview of selected colors ### How to use 1. Use the color picker to select your desired color 2. View the color value in HEX, RGB, and HSL formats 3. Click any color code to copy it to your clipboard 4. Adjust hue, saturation, and lightness as needed ### FAQ **Q: Which colour format should I use in CSS?** A: For most modern projects, HSL is easier to reason about (the numbers map to hue, saturation, and lightness), while HEX is shorter in shared snippets. RGBA and HSLA let you set transparency. Pick whichever keeps your stylesheet readable — browsers render them identically. **Q: Why does the HEX value have eight characters?** A: Eight-character HEX (e.g. #112233FF) includes an alpha channel — the last two characters encode transparency from 00 (invisible) to FF (fully opaque). Strip them if you only need the six-character opaque form. **Q: Do I need to worry about colour spaces like P3 or OKLCH?** A: Not for standard web work. The picker stays in sRGB, which is what every browser, CSS value, and design tool assumes by default. Wide-gamut spaces like Display-P3 matter for high-end photography and cinema, not typical UI work. **Q: Is this accessible? Does it check contrast?** A: The picker shows you the colour, but it doesn't yet score WCAG contrast. For now, pair it with a dedicated contrast tool to verify text readability against your chosen background — especially for body copy and interactive elements. **Q: Why does the same HEX code look different on my monitor and my phone?** A: Each display has its own calibration — colour temperature, gamma, and gamut vary. sRGB is the lowest-common-denominator your browser assumes, but phones often render with wider gamuts and bolder saturation. For brand-critical colours, hard-calibrate against a reference device rather than trusting any one screen. **Q: Can I copy a colour directly from an image?** A: Not yet — the picker starts from a colour you select visually, not from image input. If you need to sample a colour from a screenshot, use your OS's built-in colour picker (Digital Color Meter on macOS, Snipping Tool on Windows) and paste the HEX back in. --- ## Box Shadow Generator URL: https://cleanweb.tools/tools/box-shadow-generator Tags: css, box shadow, design, visual, generator Design beautiful CSS box shadows with an intuitive visual editor. Adjust horizontal and vertical offset, blur, spread, color, and opacity. Copy the generated CSS code instantly. ### Features - Visual editor for CSS box shadow properties - Adjust offset, blur, spread, color, and opacity - Support for multiple shadows and inset shadows - Copy generated CSS code instantly ### How to use 1. Use the sliders to adjust shadow properties 2. Set horizontal and vertical offset, blur, and spread 3. Choose shadow color and opacity 4. Copy the CSS code and paste it into your stylesheet ### FAQ **Q: What's the difference between box-shadow and filter drop-shadow?** A: box-shadow tints a rectangle around the element's border box, ignoring transparent pixels inside. filter: drop-shadow casts a shadow of the actual painted shape — useful for PNGs, SVGs, and rounded clip-paths where you want the shadow to hug the content, not the bounding box. **Q: How do I make the shadow look more natural?** A: Use larger blur than offset, and a translucent shadow colour (rgba(0,0,0,0.1) instead of solid black). Real shadows are soft and faint; designers new to CSS tend to use 5 5 0 0 black, which looks like clip-art. Two stacked shadows — one tight, one diffuse — also mimic real light. **Q: Can I stack multiple shadows?** A: Yes — comma-separate them in the box-shadow value. The first shadow renders on top. Stacks of 3–5 shadows with increasing blur and decreasing opacity produce realistic elevation (the "Material Design" look is essentially this). **Q: Does box-shadow trigger repaints on scroll?** A: Only the first paint is expensive. After layout, the shadow is rasterised and reused. Animating the shadow directly (e.g., on hover) is the costly case — prefer animating a secondary element or using opacity on a pre-rendered pseudo-element. **Q: Is inset different from outer shadow?** A: Yes — inset shadows render inside the border, like the element is pressed in. Use them for focus rings on tactile-looking buttons, sunken panels, or highlighting scrollable overflow. They stack with outer shadows in the same box-shadow value. --- ## CSS Gradient Generator URL: https://cleanweb.tools/tools/gradient-generator Tags: css, gradient, design, colors, generator Design stunning CSS gradients with an easy-to-use visual editor. Create linear or radial gradients, add multiple color stops, adjust angles, and copy the generated CSS code. ### Features - Create linear and radial CSS gradients visually - Add and customize multiple color stops - Adjust gradient angle and direction - Copy the generated CSS gradient code ### How to use 1. Choose between linear or radial gradient type 2. Add color stops and adjust their positions 3. Set the gradient angle or direction 4. Copy the CSS code for your project ### FAQ **Q: When should I use radial instead of linear?** A: Use radial for spotlight effects, vignetting, and anything where a single point of interest radiates outward (hero backgrounds, skeleton-loader shimmer). Use linear for sky-to-ground effects, section dividers, and most button or panel backgrounds. When in doubt, pick linear — it's the more neutral default. **Q: Why do my gradients look banded from near-black to colour?** A: That's an 8-bit colour-depth limit — you can only have 256 intermediate steps per channel. Mitigate with a wider hue range (avoid dark-to-near-dark), added noise texture, or a wider-gamut colour space like oklch() which spreads perceptual steps more evenly. **Q: Can I animate a gradient?** A: Not directly — CSS can't interpolate between two gradient values. Workarounds: animate background-position on an oversized gradient, fade between two layered gradients with opacity, or use conic-gradient inside an @property for browsers that support animatable custom properties. **Q: What's the difference between linear, radial, and conic gradients?** A: linear-gradient goes in a straight line; radial radiates from a point; conic sweeps around a point like a clock hand. Conic is what you'd use for pie charts, colour wheels, and circular loaders. All three support the same colour-stop syntax. **Q: Why does my gradient have a visible seam?** A: Usually because the first and last colour stops don't match. For seamless conic gradients, start and end on the same colour. For linear backgrounds that repeat, make sure stops are placed at 0% and 100% and match. For radial, place a matching stop at the outer edge. --- ## Aspect Ratio Calculator URL: https://cleanweb.tools/tools/aspect-ratio-calculator Tags: aspect ratio, dimensions, resize, image, video Calculate aspect ratios, resize dimensions while maintaining proportions, and convert between common ratios like 16:9, 4:3, and 1:1. Essential for designers working with images, videos, and responsive layouts. ### Features - Calculate aspect ratios from width and height - Resize dimensions while maintaining proportions - Common presets for 16:9, 4:3, 1:1, and more - Perfect for responsive design and media sizing ### How to use 1. Enter the width and height of your image or video 2. View the calculated aspect ratio 3. Enter a new width or height to resize proportionally 4. Use preset ratios for common media formats ### FAQ **Q: Why is 16:9 the standard for video?** A: HDTV and YouTube settled on it in the 2000s as a compromise between 4:3 television (too square) and cinematic 2.35:1 (too wide for home viewing). Every modern platform — phones held sideways, laptops, TVs, Twitch — is built around 16:9. Shooting 9:16 vertical is a recent break for mobile-native platforms. **Q: What aspect ratio should I use for Instagram?** A: Instagram accepts multiple, but three are worth remembering: 1:1 square for the feed (still works everywhere), 4:5 portrait for feed (maximises screen space), 9:16 for Stories and Reels. Post a 4:5 on the feed to take more vertical real estate than a 1:1 neighbour. **Q: Does cropping to an aspect ratio lose image quality?** A: Cropping itself doesn't — you're just discarding pixels. Resizing (scaling up or down) is what loses information. If your original is larger than the target, crop then scale down, which preserves detail. Never scale up and then crop. **Q: What's the difference between aspect ratio and resolution?** A: Aspect ratio is a shape (16:9, 4:3). Resolution is a pixel count at that shape (1920×1080, 3840×2160). A 16:9 video at 1080p and a 16:9 video at 4K have the same shape and display behaviour — 4K just has four times the pixels. **Q: Why is 2.39:1 called "widescreen cinema"?** A: It's the anamorphic 35mm format: squeezed onto a 4:3 frame during shooting, then stretched back during projection. Hollywood's 2:35 (older) and 2.39:1 (current) are both called "widescreen". Trying to fit that ratio on a 16:9 TV is why you get letterboxing. --- ## Favicon Generator URL: https://cleanweb.tools/tools/favicon-generator Tags: favicon, icon, website, branding, generator Generate favicons in multiple sizes from any image. Create ICO files and PNG icons for different devices and browsers. Preview how your favicon will look in browser tabs. ### Features - Generate favicons from any image or SVG - Create multiple sizes for different devices - Preview how favicons look in browser tabs - Customize with rounded corners, backgrounds, and tinting ### How to use 1. Upload an image or SVG file 2. Customize the favicon appearance with styling options 3. Preview the favicon in a simulated browser tab 4. Download the generated favicon files ### FAQ **Q: Which favicon sizes do I actually need?** A: The practical minimum set in 2026: a 32×32 PNG for most browser tabs, a 180×180 apple-touch-icon for iOS, and an SVG favicon for dark-mode-aware rendering. The old ICO file with 16/32/48 sizes is worth shipping for Windows legacy, but PNG+SVG is what renders in modern browsers. **Q: Is an ICO file still necessary?** A: For broad compatibility, yes — Edge on Windows still pulls from /favicon.ico when nothing else is declared. But once you have a `` in your head, the ICO fallback is only for URL-bar favicons in a handful of legacy places. **Q: Why does my favicon look blurry?** A: You're probably upscaling a small image. Favicons need to be authored at the target size or in vector form. If you start from a 16×16 PNG and export at 512×512, it'll be blurry. Start from an SVG or a canvas 512×512 or larger, and downscale for each size you need. **Q: Should I support dark mode with my favicon?** A: If you have one — use an SVG with a @media (prefers-color-scheme: dark) block inside. Chromium and Firefox apply the right variant based on the browser theme. It's a small touch that keeps your favicon visible against dark browser chrome. **Q: Can I animate a favicon?** A: Yes — animated GIFs and canvas-injected favicons work. Notification-dot libraries like Favico.js update the favicon live (unread counts, status). But browsers throttle favicon updates, so don't expect 60fps; a tick every few seconds is the practical ceiling. --- # Marketing Index: https://cleanweb.tools/tools/category/marketing ## Word & Character Counter URL: https://cleanweb.tools/tools/word-counter Tags: word count, character count, seo, content, writing A comprehensive text analysis tool that counts words, characters (with and without spaces), sentences, and paragraphs. Track reading time estimates and get detailed statistics about your content. Perfect for writers, marketers, and SEO specialists. ### Features - Count words, characters, sentences, and paragraphs - Track characters with and without spaces - Estimate reading time for your content - Real-time counting as you type ### How to use 1. Paste or type your text into the input area 2. View word, character, sentence, and paragraph counts instantly 3. Check the estimated reading time 4. Use the stats for SEO optimization or content planning ### FAQ **Q: How is reading time estimated?** A: The default assumes 200–250 words per minute for silent reading of ordinary prose, which is what most blog platforms (Medium, Substack) cite. Technical content skews slower (~150 WPM); simple copy skews faster. Use the number as a rough expectation, not a contract. **Q: Why is my word count different from Microsoft Word's?** A: Word counts hyphenated compounds, contractions, and numbers with embedded commas slightly differently than most web tools. The difference is usually under 2%. For academic or legal contexts where exact counts matter, rely on the one tool your audience will check against. **Q: Does this count characters including spaces?** A: Both — the counter shows characters with spaces (what Twitter, SMS, and form inputs care about) and without spaces (what some academic word-limits call for). For meta descriptions and SEO titles, use the "with spaces" number, since search engines count visual width. **Q: Is there a character limit on the input?** A: The browser comfortably handles a few megabytes of text. Past that, counting stays accurate but the UI can jitter as you type. For book-length manuscripts, prefer a desktop editor with dedicated statistics. **Q: How does it count sentences for non-English text?** A: It looks for ., !, ?, and their Unicode equivalents (。, ！, ？). Languages that don't use spaces between words (CJK) will under-count words — the counter assumes space-delimited tokens. Arabic and Hebrew work normally because they still use whitespace. --- ## Meta Tag Generator URL: https://cleanweb.tools/tools/meta-tag-generator Tags: meta tags, seo, open graph, twitter cards, marketing Fill in your page's title, description, canonical URL, and share image once, and get a complete head-ready block covering the basic SEO pair, the Open Graph cluster (og:title, og:description, og:image, og:url, og:type), and the Twitter Card variant — so your link renders correctly in Google SERPs, LinkedIn previews, Slack unfurls, iMessage, and X cards without you having to remember which platform expects which tag. A live preview shows how the result will look in a Google snippet and a generic social card, with character-count hints so titles and descriptions don't get truncated mid-sentence. Handy when you're shipping a static landing page without a framework, adding meta tags to a CMS template that doesn't have an SEO plugin, or sanity-checking what a hand-written Next.js generateMetadata is emitting. ### Features - Generate title and description meta tags - Create Open Graph tags for social media sharing - Generate Twitter Card meta tags - Preview how your page appears in search results ### How to use 1. Enter your page title and description 2. Fill in Open Graph and Twitter Card fields 3. Preview the search result and social media appearance 4. Copy the generated HTML meta tags to your page ### FAQ **Q: How long should my meta description be?** A: Aim for 120–160 characters. Google truncates most snippets around 155–160 on desktop and shorter on mobile. Write a complete sentence that invites a click — keyword stuffing no longer helps, since Google frequently rewrites descriptions based on query intent anyway. **Q: Do I still need Twitter Card tags if I already have Open Graph?** A: For most cases no — X falls back to Open Graph when Twitter Card tags are missing. You only need explicit twitter:card tags when you want a different card variant (summary vs summary_large_image) than your og:image would otherwise trigger. **Q: What's the right og:image size?** A: 1200×630 is the universally safe size: it satisfies X large card, LinkedIn, Facebook, and Slack. Keep any text inside the inner 1000×500 safe zone so nothing gets cropped on smaller previews, and keep the file under 1 MB so scrapers don't time out. **Q: Does my page need a canonical tag?** A: Yes, if the same page is reachable via multiple URLs (with/without trailing slash, different query parameters, paginated views). A self-referencing canonical also helps on sites with no duplicates because it gives Google an unambiguous preferred URL to index. **Q: Do meta keywords still do anything?** A: Not for Google, Bing, or DuckDuckGo — they've been ignored for over a decade. Some small regional search engines still read them, but the ranking weight is near zero. If you want search engines to understand topicality, write descriptive body content and use structured data instead. **Q: How do I stop Google from rewriting my meta description?** A: You can't fully — Google pulls snippets from body copy when it thinks they'll answer a query better. What you can do is write a description that directly answers the target query and uses words from the page body. That raises the chance Google keeps it. --- ## UTM Link Builder URL: https://cleanweb.tools/tools/utm-builder Tags: utm, tracking, analytics, campaign, marketing Build UTM-tagged URLs to track your marketing campaigns in Google Analytics. Add source, medium, campaign, term, and content parameters to any URL for accurate attribution tracking. ### Features - Build UTM-tagged URLs for Google Analytics tracking - Add source, medium, campaign, term, and content parameters - Validate and preview the final tagged URL - Copy the complete UTM link to clipboard ### How to use 1. Enter the destination URL for your campaign 2. Fill in UTM parameters: source, medium, and campaign name 3. Optionally add term and content parameters 4. Copy the generated UTM link for your campaign ### FAQ **Q: Which UTM parameters are required?** A: GA4 only requires utm_source for the traffic to count as campaign traffic; the rest are optional. In practice, always include source + medium + campaign — they're what GA dashboards group by. utm_term and utm_content are optional and mostly useful for paid search and A/B tests. **Q: Should I use lowercase for UTM values?** A: Yes — UTM values are case-sensitive in GA4. "Newsletter" and "newsletter" become two separate campaigns, which fragments your reports. Pick one convention (usually all-lowercase with hyphens) and enforce it. The builder normalises by default. **Q: Do UTM parameters affect SEO?** A: Slightly — they create duplicate URLs unless you canonical them to the clean version. Most CMSs and analytics strip UTM params from the canonical automatically. If you control the page, double-check that your canonical link doesn't include ?utm_* parameters. **Q: Can I track non-HTTP campaigns with UTMs?** A: Yes — UTMs just need to reach the browser eventually. QR codes on billboards, printed flyers, podcast episodes, email signatures — any link that eventually becomes a URL click can carry UTM tags. For offline campaigns, a short memorable UTM is better than a long accurate one. **Q: What's the difference between utm_source and the "source" dimension in GA?** A: They're the same — GA reads utm_source into its "source" dimension and utm_medium into "medium". If a visit arrives with no UTM, GA infers source and medium from the referrer (google/organic, direct/(none), etc.). UTMs override that inference. --- ## QR Code Generator URL: https://cleanweb.tools/tools/qr-code-generator Tags: qr code, generator, barcode, marketing, share Turn a URL, a Wi-Fi credential, a contact card, or any short string into a QR code you can print, share on a slide, or embed in a flyer. The generator defaults to high error-correction (level H), which means the code stays scannable even if a logo overlay or a coffee stain covers up to 30% of the surface — handy for posters, restaurant menus, and tickets that will live in the real world. Tweak foreground and background colours to match brand guidelines (just keep enough contrast — faded grey on white stops scanning fast), and download the result as a PNG in the exact pixel size your design needs. Everything is rendered locally, so internal links you wouldn't want a third-party QR service to log stay private. Useful for product packaging, event badges, restaurant tables, and anywhere a user needs to pick up a URL without typing it. ### Features - Generate QR codes from text, URLs, or any data - Customize QR code colors and size - Download QR codes as PNG images - Instant preview as you type ### How to use 1. Enter the text, URL, or data to encode 2. Customize the QR code colors if desired 3. Preview the generated QR code 4. Download the QR code image for use ### FAQ **Q: Can someone track who scans a QR code I generate here?** A: Not through this tool — the code you download points directly to whatever URL you entered, with no redirect, analytics, or tracking parameter in the middle. If you want per-scan analytics, encode a short-link from a service like Bitly instead of the final URL. **Q: What size should I export my QR code at?** A: A good rule: the printed size in millimetres should be at least 10× the scanning distance in metres. So a sign read from 2 m away needs at least a 20 mm square. Pixel resolution matters less — a 600×600 PNG prints crisply at any business-card size. **Q: Can I put my logo in the middle of the QR code?** A: Yes, within reason. Keep the logo under about 20% of the code's total area and keep it centred, so the redundant error-correction bytes can still reconstruct the missing modules. Oversized or off-centre overlays eat into the data and start breaking scans on older phones. **Q: Why use a QR code instead of just writing the URL?** A: They shave seconds off the handoff — no typing, no autocorrect mangling the domain. They're especially good for URLs with UTM tags or auth tokens no user would ever type correctly, and for offline-to-online flows like posters, packaging, and receipts. **Q: Do QR codes expire?** A: The code itself never expires — it's just an image of whatever string you encoded. What can expire is the URL inside: if you encode a short-link that gets disabled, the code now points to a dead page. For long-lived printed codes, encode the canonical URL directly or a redirect you control. **Q: Why does my QR code look different from others with the same URL?** A: QR codes have several masks and error-correction levels, each producing a valid but visually different pattern for the same input. Decoders don't care which pattern is used. If you need visual consistency across a campaign, generate all codes with the same error-correction level. ### Variants #### URL QR Code URL: https://cleanweb.tools/tools/qr-code-generator/url A URL QR code encodes any web address (with or without query parameters and UTM tags) into a pattern that phones recognise natively. Every modern phone camera — iOS 11+, Android 8+, and every major camera app — detects QR codes automatically and shows a "tap to open" notification. No app install required; no domain-specific scanner needed. That universal recognition is why QR codes beat NFC for one-shot handoffs: the user doesn't have to unlock and tap a phone to a surface, they just aim the camera from across the room. Best practices: keep the encoded URL as short as possible — not for information density (even a 200-character URL fits comfortably in a level-H code) but for scannability at distance. Shorter URLs produce fewer modules, which means bigger pixels at the same printed size. Encode the canonical URL directly rather than a Bitly redirect unless you specifically need per-scan analytics — you pay the redirect in latency and you lose the user forever if the short-link service disappears. If you need analytics, use UTM parameters on the encoded URL and measure with your own platform. Typical use cases: landing pages on print ads, "scan to download" prompts in app store campaigns, restaurant menus, event posters, product packaging, business cards, trade-show signage, and "scan to tip" replacements for paper receipts. Generated at level-H error correction by default, so the code remains readable even with a 20% logo overlay or partial occlusion. **Q: Should I encode a short link or the full URL?** A: Full URL if you control the destination. Short link only if you need per-scan analytics. Redirect short-links add latency and create a single point of failure — if the short-link provider ever turns off the URL, your printed code is dead. Direct URLs always work. **Q: Do URL QR codes work without internet?** A: Scanning works offline — the phone recognises the code and shows the URL. Opening the page obviously needs connectivity. Some apps queue the URL to open when the device reconnects. Put static information in the URL (like a ticket reference) so the scan still produces something useful offline. **Q: How do I track scans of a URL QR code?** A: Add UTM parameters to the URL before encoding (e.g., ?utm_source=poster&utm_medium=qr). Your analytics platform attributes scans the same way as any other tagged visit. For ad-hoc tracking, a per-campaign short-link also works but adds a redirect hop. **Q: Will a URL QR code work on an older phone?** A: Native camera scanning requires iOS 11+ (2017) or Android 8+ (2017), so effectively every phone in use today. Older devices need a dedicated scanner app — still widely available but adds friction. For a 2026 audience, assume native scanning and don't print "scan with any QR app" instructions. #### WiFi QR Code URL: https://cleanweb.tools/tools/qr-code-generator/wifi A WiFi QR code encodes the network name (SSID), password, and security type in a format every major phone understands natively. iOS 11+ and Android 10+ recognise WIFI: codes, show a "connect to [network]" prompt, and join without the user ever typing a password. It's the friction-free replacement for "ask the barista for the WiFi password" or pinning a password to a kitchen whiteboard. The encoded string follows a semi-standardised format: WIFI:T:;S:;P:;H:;; where auth-type is WPA, WPA2, WEP, or nopass (for open networks). Escape reserved characters (backslash, semicolon, comma, colon, quotes) with a backslash if they appear in your SSID or password. Hidden networks need H:true and the SSID passed explicitly, since the phone can't discover the network by broadcasting. Typical placements: framed poster near a coffee-shop counter, sticker on the back of a guest bedroom door in a rental, under the desk in a shared coworking space, on the WiFi router itself for household members. Security note: anyone who can see the printed QR code has your password, so don't post it in public-facing spaces for a network that also has access to sensitive LAN resources. For guest networks (isolated from internal traffic), the convenience usually outweighs the risk. **Q: What goes in the WIFI: string exactly?** A: WIFI:T:WPA;S:MyNetwork;P:MyPassword;;. T = security type (WPA, WPA2, WEP, or nopass). S = SSID. P = password. H = hidden (optional, true/false). Escape backslash, semicolon, comma, and colon with a backslash inside SSID or password values. **Q: Does iOS support WiFi QR codes natively?** A: Yes, since iOS 11 (2017). Point the camera at the code, tap the notification banner, and iOS joins the network — no password typed. Android 10+ supports the same format. Older Android versions need a dedicated scanner app. **Q: Is a WiFi QR code less secure than typing the password?** A: Functionally identical — the password is the same either way, just transferred differently. The risk shifts: instead of the password being written down on a sticky note, it's printed in a QR. Anyone who can photograph or scan the code has the password. For guest networks (isolated LAN), convenience wins. **Q: Can I make a QR code for a hidden network?** A: Yes — set H:true in the WIFI: string. The phone can't auto-discover the SSID, so the QR code supplies the network name explicitly and the phone joins directly. Without the H:true flag, the phone scans visible networks first and fails to find a hidden one. #### vCard QR Code URL: https://cleanweb.tools/tools/qr-code-generator/vcard Spec: RFC 2426 (vCard 3.0) A vCard QR code encodes a contact record in the vCard 3.0 format (RFC 2426) — the same format email clients and address-book apps have used for decades. When scanned, the phone prompts "Add [Name] to Contacts" and stores the record natively. It's the professional replacement for a paper business card: no typing, no OCR mistakes, no "I'll put that number in later" that never happens. The encoded string starts with BEGIN:VCARD, lists fields line-by-line (FN for full name, ORG for organisation, TEL for phone, EMAIL for address, URL for website, TITLE for job title, ADR for address), and ends with END:VCARD. vCard 3.0 is the most widely supported version across iOS, Android, and macOS Contacts — vCard 4.0 exists but parsing is patchier on older devices. Multiple phone or email fields with different types (TEL;TYPE=WORK vs TEL;TYPE=CELL) are allowed. Typical placements: printed business cards (next to or instead of text contact details), conference name badges, speaker slides during an introduction, email signatures (as a small inline image), trade-show booths. The QR is especially useful at networking events where attendees stack a dozen cards in an hour — a vCard scan lands the contact directly in Contacts, searchable forever, while paper cards sit in a drawer and get thrown out. **Q: What vCard version should I use for QR codes?** A: vCard 3.0 (RFC 2426) — the widest-supported format across iOS Contacts, Android Contacts, and macOS. vCard 4.0 is newer but parsing varies. 2.1 is archaic. Stick with 3.0 unless a specific system demands otherwise; every phone made this decade handles 3.0 correctly. **Q: Can I include a photo in a vCard QR code?** A: Technically yes (PHOTO;ENCODING=BASE64;TYPE=JPEG:...) but in practice no — embedding an image blows past a QR code's comfortable data limit and the resulting code becomes huge and hard to scan. If you need a photo, link to a URL (PHOTO;VALUE=URI:https://...) instead. **Q: Will a vCard QR work on my business card?** A: Yes — print it at ~15mm minimum on card stock. Put it on the back face with a "scan to save" label. At normal reading distance (~30cm), a 15mm code scans instantly. Don't shrink below that or thermal-printer jitter can corrupt enough modules to break the scan. **Q: How many fields can I include?** A: Dozens — name, nickname, multiple phones, multiple emails, address, organisation, title, URL, birthday, note. The practical ceiling is around 400 characters of content before the QR code needs high error-correction settings or becomes too dense to scan at card size. Keep the essentials; skip fax numbers and assistant info. #### Text QR Code URL: https://cleanweb.tools/tools/qr-code-generator/text A plain-text QR code encodes arbitrary text that appears as-is when scanned. No URL scheme, no vCard structure, no WiFi auto-connect — the phone shows the decoded text and offers to copy it. Useful when you want the scan to hand off information rather than trigger an action: a seat-pairing assignment at a wedding, a password you want a user to verbalise, a puzzle clue, a serial number, a short poem printed on a card, a pickup code at a shop. QR codes can technically encode a lot — up to 7,089 numeric digits or 4,296 alphanumeric characters in a single version-40 code at low error correction. In practice, aim for under 300 characters if you want a code that scans reliably from a phone camera at desk distance. Past that, the modules get small, error correction eats into capacity, and scans start failing on anything but perfectly-printed surfaces. The scanning experience varies slightly by phone: iOS shows the text in a Safari-adjacent preview and offers "Copy". Android typically shows the text in a system scanner with a copy button. Neither auto-opens anything, which is why text is the safest default for non-URL content — no accidental navigation, no app prompts, just the raw string. **Q: How much text can a QR code hold?** A: Up to 4,296 alphanumeric characters theoretically, but pragmatically target under 300 for reliable scanning from a phone camera. More characters means tinier modules, which means scans fail on anything but perfectly-printed surfaces. **Q: Does a text QR code open anything automatically?** A: No — phones show the decoded text with a "copy" or "share" option but don't open any app or URL. That's the safety property of plain-text: no scheme, no accidental navigation, no app prompt. Users copy the text or read it manually. **Q: Can I put code snippets in a QR?** A: Yes, up to the length limit. Useful for workshop handouts where attendees can scan a short function signature, a config string, or a command to run. Paste it into your phone and forward via email or copy to your laptop. Large snippets should link to a gist instead. **Q: Is the text in a plain QR visible to anyone who scans it?** A: Yes — QR is not encryption. Any scanner (including passers-by with a camera app pointed at your printed code) decodes the text. Don't encode secrets in a text QR that's visible in public. For shared credentials, use a QR on a page that requires authentication to view. --- ## URL Slug Generator URL: https://cleanweb.tools/tools/slug-generator Tags: slug, url, seo, permalink, generator Transform any text into clean, SEO-friendly URL slugs. Removes special characters, converts spaces to hyphens, and handles unicode characters. Essential for content management and blog posts. ### Features - Convert any text into clean URL-friendly slugs - Remove special characters and handle unicode - Convert spaces to hyphens automatically - Copy the generated slug to clipboard ### How to use 1. Type or paste your title or text into the input 2. View the generated slug in real-time 3. Adjust settings if needed for custom separators 4. Copy the slug for use in your CMS or website ### FAQ **Q: Why are hyphens preferred over underscores in URL slugs?** A: Google treats hyphens as word separators and underscores as part of the word. So "my-post" is read as "my post"; "my_post" is read as "mypost" and doesn't rank for "my" or "post" individually. Hyphens also look better in printed URLs and are easier to remember. **Q: Should slugs be lowercase?** A: Yes. HTTP paths are technically case-sensitive, but most routing treats /About and /about as the same page — except when it doesn't, and you end up with duplicate content. Lowercase slugs side-step that entirely. It's the default behaviour of every major CMS. **Q: How long should a slug be?** A: Short enough to read, long enough to carry your 1–2 primary keywords. 3–6 words is typical; 40–60 characters is a good ceiling. Slugs longer than that get truncated in shares and look spammy. Strip stop words ("the", "a", "of") unless they change the meaning. **Q: What does the generator do with accented characters?** A: It transliterates them to ASCII equivalents by default (é → e, ü → u, ñ → n). That's the right default for English indexing — Google normalises accented characters anyway. If your audience is non-English, keep the accents; modern browsers handle Unicode URLs fine. **Q: Can I change a slug after the post is published?** A: You can, but don't without a 301 redirect from the old slug. Changing URLs invalidates external links, SERP rankings, and social shares. Most CMSs auto-create redirects when you edit a slug; confirm yours does before changing anything already indexed. --- ## Social Preview Generator URL: https://cleanweb.tools/tools/social-previews Tags: social media, preview, mockup, screenshot, og image, twitter Generate stunning social media preview images by placing your website screenshots in a sleek MacBook-style laptop frame. Choose from beautiful gradient backgrounds, select the perfect size for Twitter, LinkedIn, Facebook, and more. Export as high-quality PNG for your social sharing needs. ### Features - Create social media preview images with laptop mockups - Choose from beautiful gradient backgrounds - Select preset sizes for Twitter, LinkedIn, and Facebook - Export as high-quality PNG images ### How to use 1. Upload a screenshot of your website or app 2. Select a background style and size preset 3. Preview the mockup with your screenshot 4. Export and download the image for social media ### FAQ **Q: What image size should I export for each platform?** A: Twitter/X: 1200×675 (16:9). LinkedIn: 1200×627. Facebook: 1200×630. Instagram feed: 1080×1080 (1:1) or 1080×1350 (4:5). The tool includes presets for all of these. Most platforms downscale gracefully, so 1200×630 is a safe universal size. **Q: Do I need a laptop mockup, or does a plain screenshot work?** A: Plain screenshots work but blend into noisy feeds. Mockups add visual context (this is a website, not just a photo) and make the preview feel intentional rather than improvised. For product launches and portfolio shares, mockups convert better; for quick announcements, a plain screenshot is fine. **Q: Can I use my own background image?** A: The current version ships gradient presets. For brand-consistent backgrounds (textured, photographic, or branded colour blocks), import your exported image into a design tool like Figma and add it there. Gradients cover 80% of the need; bespoke backgrounds belong in a design workflow. **Q: Where does my screenshot go after I upload it?** A: Nowhere — the image stays in your browser and is never uploaded. The preview, the mockup composition, and the exported PNG all happen client-side via the Canvas API. Useful for unreleased product screenshots that shouldn't leak to a third party. **Q: Why does my PNG look pixelated on Retina displays?** A: You're exporting at 1× resolution for a 2× display. For crisp rendering on modern laptops and phones, export at 2× — a 1200×630 canvas exports as 2400×1260. The extra pixels cost nothing to the user (modern connections swallow it) and look correct everywhere. --- # Text & Content Index: https://cleanweb.tools/tools/category/text ## Lorem Ipsum Generator URL: https://cleanweb.tools/tools/lorem-ipsum-generator Tags: lorem ipsum, placeholder, text, content, mockup Produce classical Lorem Ipsum filler in the exact shape your mockup needs — a three-word headline, a single 20-word sentence, a three-paragraph article body, or a long scroll for stress-testing scroll-restoration logic. The generator is deliberately boring: the same Lorem Ipsum corpus every other design tool uses, so stakeholders immediately recognise it as placeholder instead of confusing it for real copy. Paragraph length varies naturally so type-set mockups don't look suspiciously uniform. Handy for Figma exports that need longer text than the plugin provides, React components wired up before the copywriter is ready, email templates being QA'd for line-wrap behaviour, and CMS seeds that need hundreds of dummy entries. No API calls, no rate limits — generate as much or as little as you like. ### Features - Generate paragraphs, sentences, or words of placeholder text - Customize the amount of text generated - Copy generated text to clipboard instantly - Standard Lorem Ipsum text for professional mockups ### How to use 1. Select the type of text output: paragraphs, sentences, or words 2. Set the desired quantity 3. Click "Generate" to create placeholder text 4. Copy the result to use in your designs ### FAQ **Q: Where does Lorem Ipsum actually come from?** A: It's a scrambled passage from Cicero's De finibus bonorum et malorum, written around 45 BC. A typesetter in the 1500s reshuffled the words into the nonsense block designers have used as placeholder text ever since — exactly because it reads as text-shaped but nobody mistakes it for meaning. **Q: Should I ever ship a site with Lorem Ipsum?** A: No — search engines will index it, and real users will see it if a CMS field goes missing. Treat it as pre-production scaffolding only. Before launch, replace every instance with real copy and grep the codebase for "lorem" to be sure nothing slipped through. **Q: Does Lorem Ipsum work for non-Latin scripts?** A: Not really. It tests glyph width and line-height for Latin scripts but tells you nothing about how Cyrillic, Arabic, CJK, or Indic fonts will wrap. For those, use a language-appropriate placeholder — "текст-рыба" for Russian, 龍虎山 patterns for Chinese, etc. **Q: How is this different from a random-word generator?** A: Lorem Ipsum is a fixed corpus — the same words and sentence patterns every tool produces. That uniformity is the point: it's universally recognised as placeholder, so designers and stakeholders don't mistake it for real copy. Random-word generators look more like text but confuse readers. **Q: Can I use Lorem Ipsum with screen-reader testing?** A: Only cautiously. Screen readers will happily pronounce "Lorem ipsum dolor sit amet" in garbled pseudo-Latin, which doesn't represent how your final content sounds. For accessibility QA, swap in real-language placeholder or the actual copy before testing focus order and announcements. ### Variants #### Lorem Ipsum Paragraphs URL: https://cleanweb.tools/tools/lorem-ipsum-generator/paragraphs Paragraph-level Lorem Ipsum is the format most designers reach for first — it gives you the natural rhythm of a written article: short intro sentences, longer middle paragraphs, varied sentence counts per paragraph. The generator produces 4–8 sentences per paragraph, with sentence lengths varying between 8 and 18 words, so your typeset mockup shows the realistic block shapes real content will produce rather than the suspiciously-uniform rectangles that hand-written placeholder gives. Use paragraphs when you're laying out long-form content: a blog post template, an article body, an email newsletter, a product page that has a multi-paragraph description, a CMS preview, a privacy-policy-shaped legal page. The first paragraph always starts "Lorem ipsum dolor sit amet, consectetur adipiscing elit." because that's the canonical opening every stakeholder recognises as placeholder. Don't use paragraphs for: form labels, button copy, menu items (use sentences or words instead — paragraphs make them look like descriptions), or anywhere the final content will be short. Mismatching the length of placeholder to the length of the final copy misleads design reviews. **Q: How long is a Lorem Ipsum paragraph?** A: The generator produces 4–8 sentences per paragraph, each sentence 8–18 words. That gives an average paragraph length of around 80–140 words — close to real article writing. Real blog-post paragraphs typically run shorter (50–80 words); Lorem is slightly weightier to test layout with denser-than-average content. **Q: Do I get the same text every time?** A: No — each generation randomly picks words from the Lorem corpus, so identical counts produce different output. That's deliberate: you want to stress-test layout with content that differs from run to run, not memorise a single block. The first sentence is always "Lorem ipsum dolor sit amet…" to keep the placeholder instantly recognisable. **Q: Should I ship a page with paragraph Lorem Ipsum?** A: Never. Search engines will index it, real users will see placeholder if a CMS field goes missing, and "lorem ipsum" typically appears in both real copy and sample text, making grep-cleanup error-prone. Replace every placeholder block with real content before launch and audit the codebase for "lorem" as a final check. #### Lorem Ipsum Sentences URL: https://cleanweb.tools/tools/lorem-ipsum-generator/sentences Sentence-level Lorem Ipsum is the right choice when the final content will be a short fragment rather than a multi-paragraph block. Each sentence is 8–18 words, ending with a period. The generator produces the exact number of sentences requested, separated by single spaces (joinable into one paragraph) rather than double newlines. Typical uses: product card summaries on a grid (three sentences each), form field help text (one sentence), tooltips (one short sentence), search result snippets (2–3 sentences), email subject lines (one sentence), UX copy in dialogs and confirmation screens, navigation descriptions in a sitemap mockup, or any component where a full paragraph would overflow the intended container. Why sentences over words: using 15 bare words produces a jarring no-period block that looks like garbage. Sentences are the smallest natural unit of prose; designers reviewing the mockup read them like real copy instead of parsing them like a data dump. For counters and form values, use the word variant; for any display text, use sentences. **Q: How long is a typical Lorem Ipsum sentence?** A: 8–18 words, randomly varied per sentence. That matches the natural range of English prose sentences (short punchy ones plus longer explanatory ones). Each sentence starts capitalised and ends with a period, like well-formed copy. **Q: Can I generate a single sentence for a tooltip?** A: Yes — request 1 sentence. The generator produces one 8–18-word Latin sentence, which is about the right length for a tooltip or helper caption. For very short tooltips, generate one and trim to the first clause, or use the words variant for a sub-sentence fragment. **Q: Are the sentences grammatically Latin?** A: No — Lorem Ipsum is intentionally mangled Latin. Real Latin readers recognise the Cicero origin but find the word order and grammar nonsensical. That's the design: sentences that read as text-shaped without being mistakable for real meaning in any language. #### Lorem Ipsum Words URL: https://cleanweb.tools/tools/lorem-ipsum-generator/words Word-level Lorem Ipsum gives you raw bare word output without sentence structure. No capitalisation beyond the first word, no periods, just space-separated Latin words from the Lorem corpus. The generator produces the exact word count requested, so you can dial a mockup to fit a specific character-constrained component. Use words for: headline length testing ("How does a 7-word headline look in this typography?"), button labels, tag and category labels, truncated preview text, character-limited form fields, navigation link text, card titles, placeholder metadata like author names or dates that need to have a specific word shape for layout testing. Also useful for content-hash-density tests — filling a table with varying word counts per cell to make sure column widths respond correctly. Words is the least useful variant for paragraph-body layout testing: it misses the sentence-break rhythm real prose has. Reach for the sentences variant when you need short copy that still reads like writing, and the words variant when you explicitly want no sentence structure. **Q: What's the average word length in Lorem Ipsum?** A: About 6.3 characters — very close to average English word length (5.1 chars) plus typical Latin's slightly longer words. That's why Lorem is a good typographic stand-in: it approximates real English width without being mistaken for real English content. **Q: Can I use this for card titles?** A: Yes — pick a word count that matches the longest real title you expect (e.g., 5–7 words for product titles, 10–12 for blog post headlines) and see how the component handles it. Also try the single-word extreme ("a") to check what happens when titles are very short. **Q: Why is only the first word capitalised?** A: For readability. Word-only output without any capitalisation looks like a data dump; capitalising every word reads as Title Case, which misleads the layout review. Capitalising only the first word — sentence-like — is the middle ground: recognisable as placeholder without pretending to be anything else. --- ## Markdown Preview URL: https://cleanweb.tools/tools/markdown-preview Tags: markdown, preview, editor, documentation, readme A live Markdown editor and previewer that renders your Markdown content in real-time. Perfect for writing documentation, README files, blog posts, and any content that uses Markdown formatting. ### Features - Live Markdown rendering as you type - Support for headings, lists, links, images, and code blocks - Side-by-side editor and preview layout - Copy rendered HTML or raw Markdown ### How to use 1. Type or paste Markdown content in the editor 2. View the rendered preview in real-time 3. Use the toolbar for common formatting shortcuts 4. Copy the output for your documentation or blog ### FAQ **Q: Which flavour of Markdown does the preview use?** A: CommonMark with GitHub-Flavored Markdown extensions: fenced code blocks, tables, task lists, strikethrough, and autolinks. Pure CommonMark parsers won't render GFM tables, so the preview may show slightly more than a renderer like Python-Markdown without extensions enabled. **Q: Can I paste HTML inline?** A: Yes — raw HTML is passed through, which is how GFM handles it too. Note that when you embed Markdown inside HTML, most parsers stop treating it as Markdown on the inside; wrap the Markdown block in a line break to re-activate parsing. **Q: How do I render a Mermaid diagram or math?** A: Not in this previewer. GitHub renders Mermaid and KaTeX with special fenced blocks, but that's a GitHub extension, not core Markdown. For math, prefix with $$ and render with KaTeX in your production site. For diagrams, embed a pre-rendered image. **Q: Is my Markdown sent anywhere?** A: No — the preview runs entirely client-side. Private READMEs, internal docs, and draft blog posts never leave your browser. That matters when your content references unshipped product code or unreleased dates. **Q: Why doesn't a blank line do what I expect inside a list?** A: Markdown treats two blank lines as ending the list. One blank line between items is a loose list (each item gets

wrapping), zero is a tight list (bare text). If you need a paragraph inside an item, indent it 2–4 spaces under the bullet. --- ## Text Case Converter URL: https://cleanweb.tools/tools/case-converter Tags: text, case, convert, uppercase, lowercase Transform text between various cases including uppercase, lowercase, title case, sentence case, camelCase, snake_case, and kebab-case. Perfect for developers and content creators. ### Features - Convert text to uppercase, lowercase, or title case - Support for camelCase, snake_case, and kebab-case - Sentence case and other formatting options - Copy converted text to clipboard instantly ### How to use 1. Paste or type your text into the input area 2. Click the desired case conversion button 3. View the converted text in the output area 4. Copy the result using the copy button ### FAQ **Q: What's the difference between title case and sentence case?** A: Title case capitalises most words in a title ("A Tale of Two Cities"). Sentence case only capitalises the first word and proper nouns ("A tale of two cities"). Most style guides prefer sentence case for headlines now because it reads faster; AP Style still uses title case. **Q: How does the converter handle abbreviations like URL or API?** A: It treats them as regular words unless you're converting from camelCase or PascalCase, where it tries to preserve acronym boundaries. For exact control over "userAPIClient" ↔ "user-api-client" vs "user-a-p-i-client", you may need to post-edit — there's no perfect automatic rule. **Q: Why does my camelCase output have capital letters in the middle of numbers?** A: Because digits create an implicit word boundary in most conversion algorithms. "version2Field" becomes "version-2-field", and round-tripping to camel gives "version2Field". If you want "version2field" instead, paste your string in snake_case first, then convert. **Q: Is kebab-case the same as snake_case?** A: Same concept, different separator. kebab-case uses hyphens (url-slug-generator), snake_case uses underscores (url_slug_generator). CSS class names, URLs, and npm package names tend to use kebab; Python variables and SQL columns tend to use snake. **Q: Does this work for non-Latin alphabets?** A: Mostly — upper and lowercase conversion works for any script with cased characters (Latin, Greek, Cyrillic). Scripts without case (Arabic, Hebrew, CJK, Devanagari) pass through unchanged. Tokenisation assumes whitespace separation, so CJK input won't split into "words" the way English does. ### Variants #### camelCase URL: https://cleanweb.tools/tools/case-converter/camel-case camelCase is the dominant identifier convention in JavaScript, TypeScript, Java, Swift, and Kotlin. The first word is lowercase; every subsequent word starts with a capital letter; whitespace and punctuation disappear. So "user profile email" becomes "userProfileEmail", "first name" becomes "firstName", "API key" becomes "apiKey" (most conventions drop the all-caps treatment of acronyms beyond the first letter). When to reach for camelCase: JavaScript object keys where you control the schema, TypeScript and Java variable names, Swift property names, React prop names (className, onClick, etc.), JSON payload fields where backend and frontend are both JS/TS. Don't use camelCase for CSS class names (use kebab-case), Python variables (use snake_case), or URL paths (use kebab-case) — those ecosystems have their own conventions that camelCase fights against. Edge cases worth knowing: acronyms are handled differently across style guides. Google's JavaScript style guide says "parseHtml" (lowercase acronyms past the first letter); Microsoft and older Java conventions say "parseHTML" (all caps acronyms). Both are valid; consistency within a codebase matters more than choosing one over the other. The converter uses the more common "lowercase after first word" treatment. **Q: How does camelCase differ from PascalCase?** A: PascalCase capitalises every word including the first (UserProfile); camelCase lowercases the first word only (userProfile). JavaScript classes use PascalCase; variables, properties, and functions use camelCase. TypeScript keeps this rule. C# and .NET often use PascalCase for everything public. **Q: Should acronyms like API and URL be all-caps in camelCase?** A: Style guides split. Google JavaScript and modern TypeScript prefer "apiUrl" / "parseHtml". Older Java and Microsoft conventions prefer "APIUrl" / "parseHTML". Both parse correctly; pick one per codebase and stick to it. The converter uses lowercase-after-first-word, which is the more common modern choice. **Q: What does camelCase do with numbers?** A: Numbers get treated as word boundaries. "version 2 api" becomes "version2Api"; round-tripping gives you the same string. If you need the number glued without a capital break ("version2api"), convert to snake_case first (version_2_api), then post-process — there's no unambiguous single-step conversion. **Q: Which ecosystem uses camelCase most?** A: JavaScript and TypeScript (the dominant convention for variables, functions, and object keys). Java variable names. Swift properties. React component props. JSON API payloads generated by JS/TS backends. Python and Go explicitly avoid camelCase; PHP is split; C# uses PascalCase for most identifiers. #### snake_case URL: https://cleanweb.tools/tools/case-converter/snake-case snake_case lowercases every word and joins them with underscores. "User Profile Email" becomes "user_profile_email"; "HTTP Request Count" becomes "http_request_count". Named after its visual resemblance to a snake slithering through the words, the format emerged in Unix shell scripting and C early on and became the dominant convention in Python, Ruby, Rust identifiers, and SQL column names. When to use snake_case: Python variable and function names (PEP 8 is explicit on this), Ruby method names, Rust variable bindings (but not types — types use PascalCase), C/C++ names in older style guides, SQL column and table names (most style guides prefer snake_case because identifiers are case-insensitive by default in most databases, and underscores survive that normalisation better than camelCase does), environment variables derived from snake-cased identifiers (then uppercased to CONSTANT_CASE). Don't use snake_case in JavaScript or TypeScript unless you're specifically matching a backend schema — the JS ecosystem has settled on camelCase and snake_case fights against linters, library conventions, and destructuring ergonomics. When bridging a Python backend to a JS frontend, pick one convention at the API boundary and normalise; don't mix them in application code. **Q: Why do Python and Ruby prefer snake_case over camelCase?** A: Historical: Guido van Rossum (Python) and Matz (Ruby) both came from backgrounds where underscores-between-words was already the Unix norm. PEP 8 codified it in 2001. Readability studies are inconclusive — both conventions parse fine for humans. Consistency within a language matters more than cross-language uniformity. **Q: Should SQL column names be snake_case?** A: Yes, almost universally. SQL identifiers are case-insensitive by default (Postgres folds to lowercase, MySQL to lowercase on Linux), so camelCase columns often lose their capitalisation and become unreadable. snake_case survives case-folding intact. Most ORM conventions (Django, SQLAlchemy, Rails Active Record) assume snake_case column names. **Q: What about SCREAMING_SNAKE_CASE?** A: That's CONSTANT_CASE — snake_case uppercased. Used for constants in Python (`MAX_RETRIES`), environment variables (`DATABASE_URL`), and module-level configuration. Same structure as snake_case, just uppercased. Convert to snake_case first, then uppercase, to handle edge cases cleanly. **Q: Is snake_case an identifier in every language?** A: Yes — underscores are valid identifier characters in every mainstream programming language, including JavaScript, C, Java, Go, Rust, Python, Ruby, PHP, and Kotlin. Whether the language's idiomatic style uses snake_case is another question, but the syntax always supports it. #### kebab-case URL: https://cleanweb.tools/tools/case-converter/kebab-case kebab-case (also "spinal-case" or "train-case" in some style guides) lowercases words and joins them with hyphens. "User Profile Email" becomes "user-profile-email"; "API Request Count" becomes "api-request-count". Named after its resemblance to words skewered on a kebab, the format dominates in places where the identifier is also a surface the browser, search engine, or user interacts with: URLs, CSS class names, HTML attributes, and package names. Why kebab-case over snake_case in the web world: URLs can't contain underscores in SEO-friendly slugs (Google treats hyphens as word separators and underscores as part of the word — "my_post" is read as "mypost", which doesn't rank for either "my" or "post"). CSS class names historically couldn't use camelCase reliably (pre-IE9 had case-handling quirks in class attribute matching), so the ecosystem settled on kebab. HTML attributes are case-insensitive and would corrupt camelCase; kebab survives intact. Use kebab-case for: CSS class names, HTML data-attributes (data-user-id), URL path segments (/user-settings/account-email), npm package names (official policy — no uppercase, no underscores), URL query parameter keys in some APIs, CLI flag names (--dry-run), filenames for human-readable docs (user-guide.md), HTML custom element names (required to contain a hyphen per spec). **Q: Why are npm package names required to use kebab-case?** A: npm policy since the registry's earliest days: package names must be URL-safe and filesystem-safe across all major operating systems. That rules out uppercase (case-insensitive filesystems collide) and underscores (most package-name conventions in the wider JS world were already kebab). The policy is enforced at publish time. **Q: Are hyphens better than underscores in URL slugs for SEO?** A: Yes, and the difference is real. Google treats hyphens as word separators and underscores as part of the word. "my-post" is read as "my post" (ranking for both words); "my_post" is read as "mypost" (ranking for neither). Matt Cutts confirmed this in 2007 and the rule has never changed. **Q: Can I use kebab-case in JavaScript variable names?** A: No — the hyphen is a subtraction operator. `const user-id = 1` is a syntax error (or worse, a subtraction). Use kebab-case only in strings, URL paths, CSS class names, and HTML attributes. For identifiers, use camelCase. **Q: What's the difference between kebab-case and "spinal-case"?** A: Same thing, different nicknames. Some style guides and libraries use "spinal-case" or "train-case" interchangeably. They all mean lowercase words joined by hyphens. You'll see "kebab" most often in JS ecosystems, "spinal" occasionally in older documentation. #### PascalCase URL: https://cleanweb.tools/tools/case-converter/pascal-case PascalCase capitalises the first letter of every word and removes whitespace and punctuation. "user profile form" becomes "UserProfileForm"; "http request context" becomes "HttpRequestContext". Named after the Pascal programming language (which used the style in its system identifiers), PascalCase is sometimes called "UpperCamelCase" to distinguish it from regular camelCase — which differs only in the first letter. When to reach for PascalCase: JavaScript and TypeScript class names (UserProfile, HttpClient), React component names (a hard requirement — JSX treats lowercase tags as HTML elements and capitalised tags as components), TypeScript interface and type names (preferred by the official TS style guide), C# classes, properties, and public methods (.NET conventions use PascalCase for almost everything public), Go exported identifiers (Go uses initial-capital as the export-visibility marker, equivalent to PascalCase for multi-word names), Swift type names, Rust types and traits (but not variables, which use snake_case). Acronym handling varies by style guide. Modern JavaScript and TypeScript favour "HttpRequest" / "ParseXml" (only first letter of acronyms capitalised beyond the initial word). Older .NET and Java style often prefer "HTTPRequest" / "ParseXML". Both parse the same; consistency per codebase matters more than picking the universally correct answer (there isn't one). **Q: Is PascalCase the same as UpperCamelCase?** A: Yes, exactly. PascalCase and UpperCamelCase are synonyms for the same style: first letter of every word capitalised, no separators. "PascalCase" is the more common name in modern documentation; "UpperCamelCase" still appears in older style guides (especially Sun's original Java conventions). **Q: Why must React component names be PascalCase?** A: JSX's naming rule: lowercase first letter = DOM element (

, ), capitalised first letter = React component (). Without this rule the transpiler can't tell components from elements. Naming a component "myButton" instead of "MyButton" will cause React to render nothing and silently fail. **Q: What's the difference between PascalCase and Title Case?** A: PascalCase has no whitespace ("UserProfile"). Title Case keeps whitespace ("User Profile"). Title Case is for display text (book titles, section headings); PascalCase is for identifiers. Converting from one to the other is just a question of whether you strip the spaces. **Q: Do Python and Ruby use PascalCase for anything?** A: Yes — class names. Python class naming (PEP 8) and Ruby class naming both use PascalCase (Python calls it CapWords, Ruby just follows the de-facto convention). Methods, variables, and constants in both languages use snake_case or CONSTANT_CASE, so the contrast between class name and method name is visual-grep-friendly. #### Title Case URL: https://cleanweb.tools/tools/case-converter/title-case Title Case capitalises the first letter of every word and preserves whitespace between words. "the great gatsby" becomes "The Great Gatsby"; "war and peace" becomes "War And Peace". The convention is primarily for display text — book titles, movie titles, newspaper headlines, chapter names in reference works, and AP-Style headlines — rather than programming identifiers. Title Case versus Sentence case: Title Case capitalises almost every word; Sentence case capitalises only the first word and proper nouns. Most style guides have moved toward Sentence case for headlines (BBC, The Guardian, much of modern web content) because it reads more quickly. AP Style, Chicago Manual of Style, and academic publishing still use Title Case for formal titles. There's no universally correct choice — match what your publication demands. Edge cases: strict Title Case keeps articles ("a", "an", "the"), conjunctions ("and", "but", "or"), and short prepositions ("in", "on", "at") in lowercase unless they're the first or last word. "The Elements of Style" not "The Elements Of Style"; "War and Peace" not "War And Peace". Simple "capitalise every word" Title Case (sometimes called "first-letter capitalisation") doesn't follow these exceptions and produces the cruder "War And Peace" output. The converter uses the simpler rule — if your target is strict AP Style, manually downcase the short words. **Q: Should I use Title Case or Sentence case for headlines?** A: Title Case for formal contexts (book titles, academic papers, AP-Style newspapers, Chicago Style references). Sentence case for modern web content, blog posts, marketing copy, and most UX writing. BBC, The Guardian, and most tech publications have moved to Sentence case; it reads faster and looks less dated. **Q: Does Title Case capitalise articles and short prepositions?** A: Strict AP and Chicago styles don't — "The Elements of Style", "War and Peace", "Born in the USA". "A", "an", "the", "and", "but", "or", and short prepositions stay lowercase unless they're the first or last word. Casual "capitalise every word" Title Case ignores this and produces less-polished output. **Q: What's the difference between Title Case and Headline Case?** A: Functionally the same in most style guides. "Headline Case" sometimes refers specifically to AP Style's sentence-like capitalisation where even proper nouns follow the headline abbreviation rules. In practice most people use the terms interchangeably. **Q: Does Title Case work for non-English languages?** A: Partly. Germanic languages (English, German, Dutch) capitalise nouns in titles; Romance languages (French, Spanish, Italian) only capitalise the first word and proper nouns. The converter applies English-style Title Case; for French or Spanish titles, use Sentence case instead. --- ## Text Diff Checker URL: https://cleanweb.tools/tools/diff-checker Tags: diff, compare, text, changes, code review Compare two blocks of text side-by-side and see exactly what changed. Highlights additions, deletions, and modifications. Perfect for code reviews, document comparison, and version tracking. ### Features - Compare two blocks of text side-by-side - Highlight additions, deletions, and modifications - Line-by-line or inline diff view - Perfect for code reviews and document comparison ### How to use 1. Paste the original text in the left panel 2. Paste the modified text in the right panel 3. View highlighted differences between the two texts 4. Use the diff output for code reviews or change tracking ### FAQ **Q: What algorithm does the diff use?** A: A variant of the Myers diff — the same algorithm Git and most diff tools implement. It finds the longest common subsequence between the two inputs in near-linear time and highlights everything else as added or deleted. For very long inputs (100 kB+), expect it to slow down. **Q: Can I diff two JSON files structurally?** A: This tool does a line-level text diff, which works on JSON but will flag reformatted-but-equivalent JSON as different. For true structural diff (order-independent, type-aware), use a dedicated JSON diff tool like json-diff or a VS Code extension; line diffing is coarser. **Q: What's the difference between line diff and character diff?** A: Line diff shows whole changed lines. Character diff highlights the specific characters within a line. Line diff reads faster for prose and code; character diff is better when the change is a typo or a single-word edit. This view defaults to line diff with inline character highlighting on changed lines. **Q: Is my input stored?** A: No — the diff runs entirely in-browser. That matters when you're comparing unreleased code, customer data, or confidential documents. Both pastes are held only in the open tab and disappear on refresh. **Q: Why does git's diff look different than the one shown here?** A: Git diffs include context lines (the default 3 lines above and below each change) and use unified-diff format. This view is more visual — side-by-side with highlighted changes. They're equivalent information, just rendered for different audiences. --- # Converters Index: https://cleanweb.tools/tools/category/converter ## Base64 Encoder & Decoder URL: https://cleanweb.tools/tools/base64-encoder-decoder Tags: base64, encode, decode, converter, developer Convert between plain text (or binary) and Base64 without switching to a terminal. Useful when you need to drop a tiny SVG straight into a CSS background-image rule, decode a JWT payload to peek at its claims, unpack an email MIME part, or generate a Basic-Auth header from "user:pass" without reaching for btoa in the dev console. UTF-8 is handled correctly, so emoji, accented characters, and non-Latin scripts round-trip exactly — no double-encoded mojibake. The whole conversion happens in your browser, which matters when the string you're decoding is someone's session token or an Authorization header. Paste, toggle encode or decode, copy the result. Works on strings up to several megabytes; for larger binary files, use the CLI. ### Features - Encode text to Base64 format instantly - Decode Base64 strings back to plain text - Handle UTF-8 characters correctly - Copy encoded or decoded output to clipboard ### How to use 1. Paste your text or Base64 string into the input field 2. Select "Encode" or "Decode" mode 3. View the converted result instantly 4. Copy the output using the copy button ### FAQ **Q: What's the difference between Base64 and base64url?** A: Standard Base64 uses + and / as the 63rd and 64th characters and = for padding. base64url (RFC 4648 §5) swaps those for - and _ and usually drops the padding, so the output is safe to drop into URLs, filenames, and JWT parts without escaping. **Q: Is Base64 encryption?** A: No. Base64 is a 1:1 reversible encoding anyone can decode — treat the output as "plain text dressed up as ASCII", not as a secret. If you're encoding a password or API token, the token is still the secret; Base64 just makes it transport-safe. **Q: Why is my Base64 output 33% longer than the input?** A: Base64 represents every 3 bytes of input as 4 printable ASCII characters — a fixed 4/3 expansion, plus up to 2 padding characters. That's the price of going from an 8-bit alphabet to a 6-bit one; it's expected, not a bug. **Q: Can I Base64-encode a binary file here?** A: For text and short binary blobs yes, but for real file conversion use the Image-to-Base64 tool (for images) or a CLI like `base64 < file.bin` for large binaries — pasting a 50 MB file into a textarea won't end well. **Q: Why does my decoded output look like random characters?** A: Either the input wasn't actually Base64, or the decoded bytes aren't valid UTF-8 text. Try switching the output mode to binary or hex, or decode with a CLI like `echo '...' | base64 -d`. Some producers also use base64url; the leading `-` or `_` is a giveaway. **Q: Is the Base64 I paste logged anywhere?** A: No. Encoding and decoding both run entirely in the browser using btoa/atob — nothing is sent to a server or stored locally. That matters because Base64 is often used to smuggle secrets (JWTs, Basic-Auth headers), and those strings shouldn't land in server logs. ### Variants #### Base64 Encode URL: https://cleanweb.tools/tools/base64-encoder-decoder/encode Spec: RFC 4648 Base64 encoding turns arbitrary bytes into a 64-character printable ASCII alphabet (A–Z, a–z, 0–9, +, /) plus the padding character =. Every 3 input bytes become 4 output characters — a fixed 4/3 expansion plus up to two padding bytes at the end. This encoder runs entirely in your browser via the native btoa API (with a UTF-8-aware wrapper for non-ASCII input), so secrets, tokens, and PII never leave the page. Typical encoding uses: inlining a small SVG or PNG directly into a CSS `background-image: url(data:image/svg+xml;base64,...)` rule to eliminate an HTTP round-trip for a tiny asset; composing HTTP Basic-Auth headers from a "user:password" string; encoding a JWT header or payload segment before signing; embedding a file attachment in a JSON API body where binary would need a separate multipart upload; packing a binary blob into a URL query parameter or cookie value. When not to use Base64: for any payload over a few hundred KB inside a JSON body — the 33% size expansion plus JSON string escaping makes it slow to parse and wasteful to transport. Use multipart/form-data or a direct binary upload instead. Never use Base64 as "encryption" — it's a 1:1 reversible encoding anyone can decode. The output is "printable ASCII dressed up to look secure", not a cipher. **Q: Does Base64 encoding handle UTF-8 correctly?** A: Yes — the encoder first converts your input to UTF-8 bytes (via TextEncoder), then Base64-encodes those bytes. Emoji, accented characters, and non-Latin scripts round-trip cleanly. Naive btoa("Ü") would throw; this tool handles it automatically. **Q: Why is the output 33% longer than the input?** A: Base64 represents every 3 bytes (24 bits) of input as 4 printable ASCII characters (24 bits spread across 4 × 6-bit symbols). That's a fixed 4/3 = 33% expansion, plus up to 2 "=" padding characters at the end. It's the cost of translating an 8-bit byte alphabet into a 6-bit printable alphabet. **Q: When should I use base64url instead of standard Base64?** A: Anywhere URL-unsafe characters would break things: URL path segments, query parameters, cookie values, JWT parts, filenames. base64url replaces + with -, / with _, and usually drops the = padding. The underlying bytes are the same; the output alphabet is the difference. **Q: Can I encode a binary file here?** A: Short binary blobs pasted as text work, but for actual files (images, PDFs, binary data) use the Image-to-Base64 tool which accepts file uploads via FileReader. For multi-megabyte files, a CLI like `base64 < file.bin` is faster and doesn't tie up your browser. #### Base64 Decode URL: https://cleanweb.tools/tools/base64-encoder-decoder/decode Spec: RFC 4648 Base64 decoding is the inverse of encoding: 4 ASCII characters back to 3 bytes, with up to 2 padding characters at the end stripped. This decoder uses the native atob API with a UTF-8 wrapper, so you can paste Base64 that originally encoded Unicode text and get the right characters back. Everything runs in your browser — the Base64 you paste, the decoded output, and the decoded bytes never leave the page. The common decoding flow: you have a JWT from an API response and want to peek at the claims (decode the middle segment, which is Base64-encoded JSON). You have an email MIME attachment and want to see what text it wrapped. You need to verify a Basic-Auth header by decoding "Basic " to "username:password". You received a data URL and want to extract the embedded content. You are debugging a backend that emits Base64 and want to confirm what it actually produced. When the decoder fails: invalid characters (spaces, newlines, non-Base64 ASCII) slipped into the input; the input uses base64url (`-`, `_`) but the decoder is strict-standard; padding was stripped and the length isn't a multiple of 4; the decoded bytes aren't valid UTF-8 (binary data that decoded successfully but can't be rendered as text). Try switching to strict/lenient modes or trim the input to just the Base64 substring. **Q: Why did my decoded output look like garbage?** A: Either the input wasn't actually Base64 (some other encoding got there by mistake), or the decoded bytes weren't valid UTF-8 text (binary data that happens to decode successfully but doesn't render as characters). If you're decoding binary, switch to a hex-view tool; if you're decoding text, check the source encoding. **Q: Can I decode a JWT here?** A: You can decode the header and payload segments (the first two "."-separated parts) — both are base64url-encoded JSON. Paste one segment at a time. The signature (third part) is raw binary and won't decode to readable text. Dedicated JWT debuggers show all three at once. **Q: What about base64url input with - and _ characters?** A: Standard Base64 uses + and /; base64url substitutes - and _ to survive URL contexts. The decoder handles both: if your input has - or _, it's normalised back to + and / before decoding. Missing padding is also inferred from the input length. **Q: Is decoding safe for sensitive data?** A: Yes — the atob call and subsequent UTF-8 decoding happen entirely in the browser. No part of your Base64 input or the decoded output is sent anywhere. Safe for decoding session tokens, API keys, JWT payloads, and Basic-Auth headers. --- ## URL Encoder & Decoder URL: https://cleanweb.tools/tools/url-encoder-decoder Tags: url, encode, decode, uri, web Encode special characters in URLs for safe transmission over the internet, or decode encoded URLs back to readable format. Essential for working with query strings, API parameters, and web development. ### Features - Encode special characters for safe URL transmission - Decode percent-encoded URLs back to readable text - Handle all special and unicode characters - Copy encoded or decoded output instantly ### How to use 1. Paste your URL or text into the input field 2. Select "Encode" or "Decode" mode 3. View the result instantly 4. Copy the output using the copy button ### FAQ **Q: What's the difference between encodeURI and encodeURIComponent?** A: encodeURI leaves structural characters (: / ? = & #) alone because it assumes you're encoding a whole URL. encodeURIComponent encodes them, because it assumes you're encoding a single query-parameter value. Use component when building query strings; use URI when passing a full URL through something picky. **Q: Why is + in my decoded output a space?** A: application/x-www-form-urlencoded (the format of HTML form submissions) encodes spaces as +, not %20. Browsers decode + to space on form posts. If the input came from a query string, that's right. If it came from a path, `+` is literal and shouldn't be converted. **Q: Should slashes be encoded?** A: Inside a query-parameter value: yes, as %2F, otherwise they'll be interpreted as a path boundary. Inside the path itself: no — encoding a slash changes the URL's meaning. The tool defaults to component-style encoding, which is the safe default for anything going after the ?. **Q: Can I encode a URL that already has encoded parts?** A: Double-encoding produces strings like %2520 (a %20 with the percent encoded again). The fix is to decode first, then re-encode. When in doubt, run the input through decode once and see if you get a readable URL back — if yes, encode that; if no, encode as-is. **Q: Is my URL logged here?** A: No — encoding and decoding run in your browser via encodeURIComponent and decodeURIComponent. That's worth noting because URLs often contain session tokens, auth codes, or OAuth state parameters you don't want captured in any third-party log. ### Variants #### URL Encode URL: https://cleanweb.tools/tools/url-encoder-decoder/encode Spec: RFC 3986 URL encoding (also called percent-encoding, per RFC 3986) replaces reserved and non-ASCII characters with a "%XX" sequence, where XX is the two-digit hex value of the byte. A space becomes %20 (or + in form-data context), a question mark becomes %3F, an em-dash becomes %E2%80%94 (three bytes in UTF-8, each encoded). This encoder uses the browser's native encodeURIComponent, which encodes every character that isn't in the safe set — the right default for single query-parameter values. Use the encoder when: building a query string programmatically and any of the values might contain reserved characters (?, &, =, #, +, /); constructing a path segment from user input that could include slashes you want to survive as literal characters; putting arbitrary text into a URL fragment (#foo bar) where the browser would otherwise mangle whitespace; generating OAuth state parameters or callback URLs where the embedded data must round-trip unchanged. Don't use encodeURIComponent on a whole URL — it'll encode the structural characters (://, &, =) that need to stay literal for the URL to parse. Use encodeURI or manual parsing for that. The rule of thumb: encodeURIComponent for values, encodeURI for full URLs, URL constructor for anything structural. **Q: Should I use encodeURI or encodeURIComponent?** A: encodeURIComponent for single values (query parameter values, path segments); encodeURI for whole URLs that still have structural characters (://, &, =) that need to stay literal. This tool uses encodeURIComponent by default because "encode this text" usually means "for a value", not "for a whole URL". **Q: Why are some characters like ~ and * not encoded?** A: RFC 3986 includes them in the "unreserved" set — safe anywhere in a URL without encoding. The unreserved set is letters, digits, and - _ . ~. Older standards (RFC 2396) encoded * and ~, but modern tools follow RFC 3986 and leave them alone. Both forms decode identically. **Q: How does URL encoding handle Unicode?** A: Unicode characters are encoded as their UTF-8 byte sequence, each byte written as %XX. "€" (U+20AC) is encoded as %E2%82%AC — three percent-escaped bytes. The decoder reverses this automatically. Non-UTF-8 source encodings (Latin-1, Shift-JIS) don't round-trip without pre-conversion. **Q: Why does a space become + in some contexts and %20 in others?** A: Query strings historically encoded spaces as + (HTML form submissions use application/x-www-form-urlencoded, which defines + = space). Modern APIs use %20. Browsers decode both correctly on the URL's query portion, but not in the path. This encoder emits %20 consistently, which is always safe. #### URL Decode URL: https://cleanweb.tools/tools/url-encoder-decoder/decode Spec: RFC 3986 URL decoding reverses percent-encoding: every "%XX" sequence becomes the byte with hex value XX, and UTF-8 byte sequences reassemble into their original characters. This decoder uses decodeURIComponent, which handles the full RFC 3986 encoded-character set and decodes UTF-8 multi-byte sequences correctly. Typical decoding flow: you have a copy-pasted URL from a browser address bar where everything is percent-encoded and you want to read the actual parameters; you're inspecting an OAuth callback URL with a long state parameter and need to see what your app encoded into it; you're reading a log line with a URL and the non-ASCII characters are unreadable; you want to verify what a frontend sent by decoding the raw query string on the backend side. When decoding fails: malformed percent sequences (%ZZ where Z isn't a hex digit), truncated sequences (% at the end with no following digits), invalid UTF-8 byte sequences that can't reassemble into characters. The decoder will throw URIError, which is a signal the input isn't valid percent-encoding. Common cause: a URL that was encoded twice (double-encoding produces %25XX instead of %XX), which you fix by running the decoder twice. **Q: Why am I getting URIError on valid-looking input?** A: Usually a stray % that isn't followed by two hex digits ("100%" would produce URIError on the trailing %), or an invalid UTF-8 byte sequence (%E9 alone isn't valid UTF-8, it needs continuation bytes). Trim the input to just the percent-encoded portion and try again. **Q: What's double-encoding and how do I fix it?** A: Double-encoding is when a URL gets percent-encoded twice, producing strings like %2520 (which is %20 with its % re-encoded as %25). The fix is to decode twice. If you run the decoder once and the output still has %XX sequences in it, decode again. Three-times encoding is rare but possible. **Q: Should I decode + as a space?** A: Depends on context. In query strings from HTML form submissions, + means space (application/x-www-form-urlencoded convention). In URL paths or fragments, + is a literal plus sign. decodeURIComponent treats + as literal; browsers handle the form-data form separately. If you're decoding a form submission, pre-replace + with space before decoding. **Q: Can I decode a URL that came from an email?** A: Yes, but emails sometimes break long URLs across lines or insert soft-wrap markers (= at end of line in quoted-printable). Remove those first. Also check if the email client already decoded some characters — pasting a half-decoded URL into this tool will fail on sequences that are already plain text. --- ## Timestamp Converter URL: https://cleanweb.tools/tools/timestamp-converter Tags: timestamp, unix, date, time, converter Convert Unix timestamps to human-readable date formats and vice versa. Support for various date formats, timezones, and instant conversion. Essential for developers working with APIs and databases. ### Features - Convert Unix timestamps to human-readable dates - Convert dates to Unix timestamp format - Support for multiple date formats and timezones - View the current timestamp in real-time ### How to use 1. Enter a Unix timestamp or select a date 2. View the converted result in the other format 3. Choose your preferred date format and timezone 4. Copy the converted value to clipboard ### FAQ **Q: Are Unix timestamps in seconds or milliseconds?** A: Classic Unix is seconds since 1970-01-01 UTC; JavaScript's Date.now() is milliseconds. If your value is around 10 digits, it's seconds; around 13 digits, it's milliseconds. The converter auto-detects by magnitude — a value like 1745000000 is assumed to be seconds. **Q: Why does the same timestamp show a different date in my app?** A: Timezones. A timestamp is a single instant, but how it displays depends on the viewer's timezone. "1745000000" is 2025-04-18 17:33 UTC but 13:33 in New York and 10:33 in San Francisco. Always display in the user's local zone unless your app needs UTC explicitly. **Q: What happens after the 2038 problem?** A: 32-bit signed Unix timestamps overflow on 2038-01-19 at 03:14:07 UTC. Most modern systems (Linux, JS, Postgres BIGINT) already use 64-bit timestamps and aren't affected. If you're still running 32-bit embedded C code, that's the year to upgrade. **Q: Can I convert dates before 1970?** A: Yes — Unix timestamps go negative for dates before the epoch. -1000000000 is 1938-04-24. JavaScript's Date handles these, but some databases (older MySQL TIMESTAMP, some APIs) reject negatives. Use DATETIME or ISO-8601 strings for historical dates. **Q: Is ISO 8601 or Unix timestamp a better database format?** A: Unix for fast range queries, simpler indexing, and timezone-neutral storage. ISO 8601 for readability in logs and CSV exports. Modern Postgres's timestamptz stores as UTC internally but displays with timezone — the best of both worlds if your database supports it. ### Variants #### Unix to Date URL: https://cleanweb.tools/tools/timestamp-converter/unix-to-date This converter takes a Unix timestamp (seconds or milliseconds since 1970-01-01 UTC) and renders it as a human-readable date in three formats simultaneously: local time (honouring your browser's timezone), UTC, and ISO 8601. The auto-detection logic looks at the number's magnitude — values around 10 digits are treated as seconds, 13 digits as milliseconds — so you can paste what you have and trust the output. Use this direction when: a backend log line or database column gave you a bare integer and you need to know when it happened; you're debugging a JWT "exp" or "iat" claim (JWT uses seconds); you're sanity-checking a Stripe event timestamp (Stripe uses seconds in most places but milliseconds in a few newer fields — the converter handles both); you're reading event data from Unix-native tooling like `ls -l --time-style=+%s`. The ISO 8601 output ends with "Z" when the date is in UTC, or with an offset like "+02:00" for local time in non-UTC zones. Most API specifications (RFC 3339 subset of ISO 8601) require the "Z" or explicit offset; "2026-04-23T10:00:00" without a zone is ambiguous and should be avoided in new interfaces. Copy whichever format matches your target API's expectations. **Q: How does the converter know if my timestamp is seconds or milliseconds?** A: It looks at the magnitude. A 10-digit number (like 1735689600) is too small to be a reasonable millisecond timestamp — it'd place the date in 1970. 13-digit numbers are treated as ms. The threshold is around 9,999,999,999. You can override by multiplying or dividing by 1000 before pasting. **Q: What timezone does the "local" output use?** A: Your browser's configured timezone — typically derived from the operating system. If you need a specific zone (e.g., "what is this timestamp in Tokyo"), use the ISO output as input to a dedicated timezone tool. The "UTC" output is always stable regardless of your location. **Q: Why is the date I converted one day off?** A: Usually a timezone confusion. A timestamp like 1735603200 is Dec 31 midnight UTC — which is Dec 30 evening in the Americas and Jan 1 morning in Asia. The local output reflects your zone; to reason about the "day" unambiguously, use UTC. **Q: Can I convert timestamps in nanoseconds?** A: Not directly — the converter expects seconds or milliseconds. For nanoseconds (common in Go's time.Now().UnixNano() or Prometheus metrics), divide by 1,000,000 first to get ms, then paste. You lose sub-millisecond precision but gain readable dates. #### Date to Unix URL: https://cleanweb.tools/tools/timestamp-converter/date-to-unix This direction takes a date and returns the corresponding Unix timestamp — seconds and milliseconds simultaneously. The input is a browser datetime-local picker, so you can type or pick a date/time value and immediately see its epoch representation. The conversion uses JavaScript's Date constructor, which accepts ISO 8601 strings, RFC 2822 date strings, and a dozen other pragmatic formats. Use this direction when: you're hard-coding a timestamp into a test fixture and don't want to run code to get it; you're configuring a scheduled job in a system that accepts Unix times (cron wrappers, AWS EventBridge, Cloudflare Workers Cron); you're filling a database seed file with timestamp column values; you're debugging whether a date-shaped config is getting parsed correctly by calculating what Unix time it would represent. The datetime-local input is timezone-naive — it records the "wall clock" time in your local zone. The conversion to Unix timestamp interprets it in UTC by default. If you need to produce a timestamp for a specific other timezone ("what is 2026-06-01 09:00 Tokyo time?"), add the offset manually (Tokyo is UTC+9, subtract 9 hours) or use a dedicated timezone-aware tool. **Q: How do I enter a specific timezone?** A: The datetime-local input is timezone-naive and gets interpreted in your local browser zone. For an explicit timezone, paste an ISO 8601 string like "2026-04-23T10:00:00+09:00" into a full-ISO parser or manually add/subtract hours. There's no clean UI for specifying arbitrary zones here. **Q: Why do I get different Unix timestamps for the same date in different browsers?** A: Browser timezone detection reads from the OS. If your OS is in different zones on different devices (a travel laptop vs home desktop), you'll get different Unix times for the same wall-clock time. Always use explicit UTC or offset for values that need to match across devices. **Q: Should I output seconds or milliseconds?** A: Depends on the consumer. Unix CLI tools, cron, JWT, most database timestamp columns, and most Unix-era APIs use seconds. JavaScript's Date.now(), newer JSON APIs, and anything derived from JS use milliseconds. The tool shows both; copy the one your target expects. **Q: Can I convert a date before 1970?** A: Yes — the result is a negative Unix timestamp. "1968-01-01" is around -63,158,400 seconds. JavaScript handles negatives natively; some databases (older MySQL TIMESTAMP) reject them. For historical dates, ISO 8601 strings are more portable than negative Unix times. #### Millisecond Timestamp URL: https://cleanweb.tools/tools/timestamp-converter/milliseconds Millisecond-precision Unix timestamps (the 13-digit values produced by JavaScript's Date.now()) are the default format for modern web APIs, WebSocket ping/pong, real-time event systems, and anything that needs sub-second precision without the complexity of nanosecond fields. This converter pre-fills the input with the current Date.now() value and emphasises millisecond output alongside the classic seconds representation. The second-vs-millisecond choice matters in a few places: JavaScript (Date.now() and new Date(ms)) always uses milliseconds. Most REST APIs that accept a timestamp in a JSON body use milliseconds. Most databases that store timestamps as an integer use seconds (except where explicitly ms — some MongoDB and CouchDB setups, InfluxDB with a precision setting). Most Unix CLI tools (date +%s, cron @reboot) use seconds. When two systems disagree — a JavaScript frontend sending ms, a Python backend expecting seconds — bugs appear as 1000× or 1/1000× date drift, often misdiagnosed as timezone issues. This variant is optimised for the JS-native case: the input starts populated with "right now in ms", the output shows ms first, and the seconds output is still there for interop. Paste any 13-digit number and get the date; pick a date and get the ms value. **Q: Why is my API timestamp 1000× bigger than expected?** A: Almost always a seconds/milliseconds mismatch. JavaScript produces milliseconds (13 digits); many backends assume seconds (10 digits). Divide by 1000 to convert ms → s, or multiply to go the other way. If the date lands around 1970 or 50,000 years in the future, you've got the unit wrong. **Q: Is milliseconds precision enough for event ordering?** A: Usually yes — two events in the same millisecond are rare in most apps. For high-frequency systems (trading, ad-bidding), add a per-process counter or use a UUID v7 which embeds a ms timestamp plus 74 random bits. For nanosecond precision, use Date.now() + performance.now() or a native API. **Q: Do database timestamp columns store milliseconds or seconds?** A: Depends on the database and column type. Postgres TIMESTAMP and TIMESTAMPTZ store microseconds internally. MySQL DATETIME(3) stores milliseconds; plain DATETIME is seconds. MongoDB Date is milliseconds. ALWAYS confirm by reading docs — wrong assumptions create off-by-1000 bugs. **Q: Is Date.now() the same across devices?** A: Close, within clock-sync error. Most devices sync via NTP within ~100 ms of real time. For events you want to compare across machines, server-side timestamps are authoritative — don't trust client clocks for anything that needs to order with other clients'. --- ## Image to Base64 URL: https://cleanweb.tools/tools/image-to-base64 Tags: image, base64, data url, embed, converter Convert images to Base64 encoded data URLs that can be embedded directly in HTML, CSS, or JavaScript. Supports PNG, JPG, GIF, and other common image formats. ### Features - Convert PNG, JPG, GIF, and other images to Base64 - Generate data URLs for embedding in HTML and CSS - Preview uploaded images before conversion - Copy the Base64 data URL to clipboard ### How to use 1. Upload an image file using the file picker or drag and drop 2. View the image preview and file details 3. Copy the Base64 data URL from the output 4. Paste the data URL directly in your HTML or CSS ### FAQ **Q: When should I inline an image instead of linking to it?** A: Tiny icons under 2 KB, or a single above-the-fold hero you don't want a separate HTTP round-trip for. Past around 10 KB, the Base64 bloat (33% expansion) plus the fact that inline images can't be cached separately starts hurting page load — link them instead. **Q: Does inlining affect caching?** A: Yes — inlined images cache with their host HTML or CSS file, not separately. If the image changes but the page doesn't, the browser still has to re-download it with the page. Good for truly one-off assets, bad for anything reused across many pages. **Q: Which image format should I base64 — PNG, JPG, or SVG?** A: SVG whenever possible — it's text, Base64 encoding costs less (since the source is already UTF-8), and it scales. For raster, prefer WebP or AVIF when browser support allows, fall back to JPG for photos, PNG for anything needing transparency. **Q: Is my image uploaded to a server?** A: No — the encoding runs in the browser via FileReader and the file never leaves your machine. This matters for screenshots with sensitive data or unreleased mockups. The resulting data URL is yours to paste into your own code. **Q: Can I decode a data URL back into an image?** A: Yes — paste the data URL (the data:image/... string) into any decoder, or save it to a file renamed to .png/.jpg. Most browsers also handle pasting a data URL directly into the address bar and will render the image. --- ## JSON to CSV Converter URL: https://cleanweb.tools/tools/json-to-csv Tags: json, csv, converter, data, spreadsheet Transform JSON arrays into CSV spreadsheet format or convert CSV files back to JSON. Handle nested objects, customize delimiters, and download results. Perfect for data migration and analysis. ### Features - Convert JSON arrays to CSV spreadsheet format - Convert CSV data back to JSON format - Handle nested objects and complex data structures - Download converted data as a file ### How to use 1. Paste your JSON or CSV data into the input field 2. Select the conversion direction (JSON to CSV or CSV to JSON) 3. View the converted output instantly 4. Copy or download the result ### FAQ **Q: How does the converter handle nested JSON?** A: Flattened by default using dot notation: {"user": {"name": "Ada"}} becomes a column "user.name". Arrays of scalars are joined by semicolons ("a;b;c"), arrays of objects become repeated rows. If your data is deeply nested, preprocess it before converting — CSV is fundamentally flat. **Q: Why does Excel mangle my CSV?** A: Usually because Excel interprets comma-separated cells per your locale — in European locales, Excel expects semicolons as the delimiter. Either export with semicolons, prepend the file with sep=,\n (Excel respects this hint), or use Excel's "Data > From Text" workflow rather than double-clicking. **Q: How do I handle commas inside values?** A: They get wrapped in double quotes: "Paris, France". The tool does this automatically per RFC 4180. If you're hand-writing a CSV, remember that embedded quotes get doubled ("She said ""hi"""), not escaped with a backslash. **Q: Is my data sent anywhere during conversion?** A: No — everything runs in your browser. That matters for customer exports, financial data, and anything with PII where sending the file to a random online converter would be a compliance issue. Paste, convert, download, move on. **Q: Should I use JSON or CSV for bulk data exchange?** A: JSON for structured data, nested objects, or anything that'll be read by code. CSV for flat, column-oriented data that'll be opened in a spreadsheet or loaded into a relational database. CSV is smaller on the wire; JSON is more self-describing. Pick based on the consumer. ### Variants #### JSON → CSV URL: https://cleanweb.tools/tools/json-to-csv/json-to-csv Spec: RFC 4180 JSON-to-CSV conversion takes an array of JSON objects and produces a header row plus one data row per object. The first object's keys become the column headers; each subsequent row is the same key order. Values containing commas, quotes, or newlines get wrapped in double quotes per RFC 4180, with embedded quotes doubled. Nested objects are flattened with dot notation — `{"user": {"name": "Ada"}}` becomes a column named `user.name`. Arrays of scalars are joined by semicolons inside the cell. Typical use cases: exporting a database query result (API returns JSON, user wants Excel) without writing code; prepping analytics data for a business user's spreadsheet; flattening a webhook payload into a format that loads cleanly into a BI tool; converting a fixture file in your test suite from JSON to CSV for a non-technical teammate to edit. Gotchas: the JSON must be a top-level array, not an object containing an array (wrap the array directly or extract it first). If objects have different keys, only the first object's keys become columns — missing values are left blank. Arrays of objects nested inside fields produce JSON-encoded cells rather than separate rows; if that's not what you want, flatten manually in code before pasting. **Q: How does the converter handle nested JSON?** A: Flattened with dot notation: `{"user": {"name": "Ada", "email": "ada@example.com"}}` becomes columns `user.name` and `user.email`. Arrays of scalars are joined by semicolons in the cell. Arrays of objects become JSON-encoded cells — flatten those manually if you want separate rows. **Q: What if my objects have different keys?** A: Only the first object's keys become column headers. Keys that appear in later objects but not the first are dropped. Keys from the first object missing in later objects produce empty cells. If your data has inconsistent shape, normalise to a superset of keys before converting. **Q: Why does my output have quotes around every cell?** A: Cells get quoted only when they contain commas, double quotes, or newlines (per RFC 4180). If you're seeing quotes on every cell, your data probably has a comma or newline in each value. Check the source — some numeric columns get exported as "1,000" strings from Excel. **Q: Can I use a different delimiter like tab or semicolon?** A: The current tool defaults to comma. For tab-separated (TSV) or semicolon-separated (European Excel default), post-process the output — JSON → CSV → find-and-replace , with \t or ;. Regional Excel versions assume semicolons, so that's a common target. #### CSV → JSON URL: https://cleanweb.tools/tools/json-to-csv/csv-to-json Spec: RFC 4180 CSV-to-JSON conversion takes a CSV with a header row and produces an array of objects where each row becomes one object. Column headers become object keys; values become object values. The parser handles RFC 4180 quoting (commas inside quoted cells, double-quote escaping, multi-line quoted values), trims whitespace, and preserves the column order via JavaScript object-key insertion order. Typical use cases: importing a spreadsheet into a codebase as a fixture; converting Excel export data for a REST API that expects JSON; loading a lookup table into JavaScript without having to hand-transform; prepping data for a JSON-based ETL pipeline from legacy CSV sources. By default all values are strings — "42" stays as "42", "true" stays as "true". This is deliberately lossless; coercing "42" to a number silently changes the type of a ZIP code column (where "01234" would become 1234) and can't be reversed. If your downstream code needs typed values, post-process each column explicitly — cast ZIP codes to string, parse prices to float, parse dates to Date. The manual step is short, the silent-coercion bugs aren't. **Q: Why are my numbers kept as strings?** A: Deliberate — auto-coercing "42" to a number would corrupt ZIP codes ("01234" → 1234), phone numbers, and any fields where leading zeros matter. The converter returns every value as a string; you cast in your downstream code where you know each column's intended type. **Q: What does the converter do with empty cells?** A: Empty string. `name,email\nAda,` produces `[{"name": "Ada", "email": ""}]`, not null. If you need nulls for absent values, post-process: `data.map(r => ({ ...r, email: r.email || null }))`. **Q: How does it handle multi-line values?** A: RFC 4180 allows newlines inside double-quoted cells. The parser recognises `"line one\nline two"` as a single field. Make sure your source actually emits quoted multi-lines — some CSV exporters break the spec and use \r\n as a field separator inside unquoted text, which ruins parsing. **Q: Will the output preserve column order?** A: Yes — JavaScript objects preserve insertion order, so the JSON stringified output lists keys in the same order as the CSV's header row. JSON specs don't require this, but every mainstream parser has behaved this way for years. Safe to rely on for display and round-tripping. ---