Blog

  • SHA-224 Hash Generator: 224-bit FIPS Digest [2026]

    SHA-224 Hash Generator: 224-bit FIPS Digest [2026]

    TL;DR: SHA-224 produces a 224-bit (28-byte / 56 hex character) hash. It’s SHA-256 with a different starting state and a truncated 224-bit output. Designed by NIST in 2004 to provide FIPS-compliant 112-bit collision resistance — useful when you need a SHA-2-family hash but want shorter output than SHA-256. Real-world use: 3DES key derivation, NIST SP 800-57 short-hash specifications, and storage-constrained contexts. Our free SHA-224 hash generator uses the browser’s native WebCrypto API.

    SHA-224 is the rarely-used cousin of SHA-256. It exists for one specific reason: NIST needed a SHA-2 family member that matched the output size of legacy 112-bit security applications (mainly 3DES key derivation and some FIPS-mandated short-hash specifications). For most modern use, SHA-256 is the default — same algorithm internally, longer output, more security margin. But if you’re maintaining a system that specifies SHA-224 for compliance, or doing 3DES key derivation per FIPS 800-57, this is the algorithm.

    Our SHA-224 hash generator uses the browser’s native SubtleCrypto.digest('SHA-224', ...) implementation. Paste text or drop a file — runs entirely on your device. This guide covers SHA-224’s design, when it’s the right pick over SHA-256, and the gotchas with internal state differences.

    SHA-224 vs SHA-256 — when each wins

    Algorithm Output Collision security Use case
    SHA-224 224 bits (56 hex) 112-bit 3DES key derivation, FIPS short-hash mandates
    SHA-256 256 bits (64 hex) 128-bit Default for new systems
    SHA-384 384 bits (96 hex) 192-bit PKI certificates, high-assurance signatures
    SHA-512 512 bits (128 hex) 256-bit Long-lived archives, when SHA-256 isn’t enough

    How SHA-224 differs from SHA-256

    Both algorithms run the same compression function on 512-bit blocks. The only differences:

    • Initial hash value (IV): SHA-224 uses a different 8-word starting state. This means truncating the SHA-256 output to 224 bits is not the same as computing SHA-224 — they produce different results.
    • Output length: SHA-224 returns 7 of the 8 final words (28 bytes); SHA-256 returns all 8 (32 bytes).
    • Performance: identical — the work is the same, only the IV and truncation differ.

    The “different IV” is critical. If you’re verifying a SHA-224 hash, you must compute SHA-224 specifically, not SHA-256-then-truncate. Get this wrong and your hashes never match.

    When you’d actually use SHA-224

    SHA-224 is uncommon in 2026. Real use cases:

    • FIPS 800-57 compliance: NIST’s key-management standard sometimes specifies 112-bit security strength, and SHA-224 is the matching SHA-2 family member.
    • 3DES key derivation: 3DES uses 168-bit keys with 112-bit security; SHA-224 produces a hash matching that strength. (3DES itself was deprecated by NIST in 2017 — most systems have moved to AES.)
    • Federal procurement specs: some old US government RFP / SOW documents specify SHA-224 explicitly. Match the spec; don’t substitute SHA-256.
    • Bandwidth-constrained protocols: 56 hex characters vs 64 saves a few bytes per message in tight protocols (extremely rare in 2026).

    For new code without a specific compliance reason, use SHA-256. The 8 extra hex characters cost nothing and you get 16 more bits of security margin.

    How to compute SHA-224 in your browser

    1. Open the SHA-224 generator
    2. Type or paste text — the digest appears live as you type
    3. Or drop a file — bytes are streamed through the browser’s WebCrypto API
    4. Click Copy. Toggle UPPERCASE or lowercase hex output
    5. For HMAC-SHA-224, enter a key in HMAC mode

    Code: SHA-224 in JavaScript

    async function sha224(text) {
      const buffer = new TextEncoder().encode(text);
      const hash = await crypto.subtle.digest("SHA-224", buffer);
      return [...new Uint8Array(hash)]
        .map((b) => b.toString(16).padStart(2, "0"))
        .join("");
    }
    
    // sha224("hello world") returns
    // "2f05477fc24bb4faefd86517156daccfa3e6488427d1f0f217f04b6e"

    WebCrypto support: Chrome 37+, Firefox 34+, Safari 11+ — universal in 2026. SHA-224 is part of the WebCrypto digest algorithm set since the spec finalised.

    Common gotchas

    • Don’t confuse SHA-224 with truncated SHA-256. SHA-224 has a different IV. sha256(x).substring(0, 56) !== sha224(x). Compute SHA-224 specifically.
    • UTF-8 encoding before hashing. Same input, different encoding, different hash. Always use UTF-8.
    • Don’t use for password storage. SHA-224, like other SHA-2 members, is too fast for password storage. Use bcrypt / argon2id with passwords.
    • Some libraries don’t ship SHA-224. Older crypto libraries (PHP’s hash() pre-7.0, some C libraries) don’t include SHA-224. Verify your destination supports it before specifying.
    • Length-extension attacks affect SHA-224 too. Like SHA-256, vulnerable to length extension if used as sha224(secret || data). Use HMAC-SHA-224 instead.
    • If you can choose, choose SHA-256. Only use SHA-224 if a spec mandates it. The 8 extra hex characters are free.

    When NOT to use SHA-224

    For new systems without compliance requirements: use SHA-256. For password storage: never SHA-224 (or any plain SHA); use bcrypt / scrypt / argon2id. For TLS / X.509 certificates: SHA-256 minimum (SHA-224 isn’t supported by most CAs). For long-lived archives: SHA-512 for the extra security margin. SHA-224 is a niche tool — match it to a specific spec, otherwise pick a sibling.

    Frequently asked questions

    Is SHA-224 just truncated SHA-256?

    No. They share the same compression function but use different initial hash values (IVs). Truncating SHA-256 to 56 hex characters does NOT produce the SHA-224 hash. Compute SHA-224 specifically using the WebCrypto API or a dedicated library.

    Should I use SHA-224 instead of SHA-256?

    No, unless a spec mandates it. SHA-224 saves 8 hex characters in output but provides 16 fewer bits of collision security. The bandwidth saving is negligible in 2026; SHA-256 is the safer default for new systems.

    Why does SHA-224 even exist?

    NIST designed it in 2004 for compliance with key-management standards that specify 112-bit security strength — matching legacy systems like 3DES key derivation. Most legacy systems have moved on; SHA-224 is now mostly used in older federal procurement specs.

    Is the WebCrypto API support universal?

    Yes — SHA-224 has been part of WebCrypto since the spec finalised in 2014. Chrome 37+, Firefox 34+, Safari 11+, Edge 12+. Universal in 2026.

    Is my input uploaded?

    No. The generator runs the browser’s WebCrypto API. Text and files are processed locally — never sent to our servers.

    Can SHA-224 be reversed?

    No. Like all SHA-2 hashes, SHA-224 is a one-way function. Given a hash, there’s no method short of brute force to recover the input. Cracking weak inputs (short passwords) involves trying candidates until one matches — defence is using slow algorithms (bcrypt) for passwords.

    Related tools and guides

     

  • SHA-384 Hash Generator: 384-bit Digest [2026]

    SHA-384 Hash Generator: 384-bit Digest [2026]

    TL;DR: SHA-384 produces a 384-bit (48-byte / 96 hex character) hash. It’s SHA-512 with a different starting state and a truncated 384-bit output. 192-bit collision resistance — overkill for most uses, but mandated in NSA Suite B / CNSA-compliant cryptography, TLS 1.3 cipher suites, and US government high-assurance systems. Faster than SHA-256 on 64-bit hardware. Our free SHA-384 hash generator uses the browser’s native WebCrypto API.

    SHA-384 occupies the same family-niche as SHA-224: a SHA-2 hash with truncated output for compliance reasons. Where SHA-224 is the truncated SHA-256 for legacy 112-bit security, SHA-384 is the truncated SHA-512 for high-security applications that don’t need a full 512-bit hash but want more than SHA-256’s 128-bit collision resistance. Real-world use is concentrated in government and high-assurance crypto:

    • TLS 1.3: the TLS_AES_256_GCM_SHA384 cipher suite uses SHA-384 in HKDF for key derivation.
    • NSA Suite B / CNSA: the US National Security Agency’s commercial cryptography spec requires SHA-384 (or SHA-512) for top-secret data classifications.
    • PKI / X.509 certificates: ECDSA signatures over P-384 curves naturally pair with SHA-384.
    • Long-lived archive integrity: the extra 64 bits over SHA-256 add comfortable security margin.

    Our SHA-384 hash generator uses the browser’s native SubtleCrypto.digest('SHA-384', ...) API — same code path that handles HTTPS certificate verification — and runs entirely on your device. This guide covers when SHA-384 is the right pick, the performance characteristics, and the gotchas with truncation.

    SHA-2 family at a glance

    Algorithm Output Collision security Performance
    SHA-224 224 bits 112-bit Same as SHA-256
    SHA-256 256 bits 128-bit Slower on 64-bit
    SHA-384 384 bits 192-bit Same as SHA-512 (faster on 64-bit)
    SHA-512 512 bits 256-bit ~30% faster than SHA-256 on 64-bit

    Why SHA-384 is faster than SHA-256 on modern hardware

    SHA-384 uses the SHA-512 compression function — operating on 64-bit words and 1024-bit blocks — and just truncates the output. On a 64-bit CPU each word fits in a single register. SHA-256, despite producing a smaller output, runs on 32-bit words requiring more operations per byte hashed.

    Benchmark on a 2024 laptop:

    • SHA-256: ~600 MB/s
    • SHA-384: ~880 MB/s (≈47% faster)
    • SHA-512: ~880 MB/s (same internal work as SHA-384)

    Counter-intuitively, picking SHA-384 over SHA-256 for new code can mean both more security and better performance on 64-bit hardware. The trade-off is 32 extra hex characters in output.

    When you’d actually use SHA-384

    • NSA Suite B / CNSA-compliant systems. US government top-secret classification mandates SHA-384 minimum. If you’re in defence / intelligence contracting, this is the spec.
    • TLS 1.3 with AES-256-GCM. The TLS_AES_256_GCM_SHA384 cipher suite is one of TLS 1.3’s three default suites. Browsers negotiate it automatically; you don’t pick it manually.
    • PKI signatures with P-384 curves. ECDSA on the NIST P-384 curve naturally pairs with SHA-384 for matching security level.
    • Compliance frameworks specifying 192-bit security. Some financial regulations (PCI DSS in select profiles), ANSSI guidelines, BSI specs.
    • Long-lived archive integrity. The 64 extra bits over SHA-256 add margin for hashes verified decades from now.

    For most everyday checksums and integrity verification, SHA-256 is the right default — universally supported, established, well-tested. SHA-384 is for compliance-driven cases.

    How to compute SHA-384 in your browser

    1. Open the SHA-384 generator
    2. Type or paste text — the digest appears live
    3. Or drop a file — bytes streamed through WebCrypto, no upload
    4. Click Copy. Toggle UPPERCASE / lowercase output
    5. For HMAC-SHA-384, click HMAC mode and paste a key

    Common gotchas

    • SHA-384 is not truncated SHA-512. Like SHA-224 / SHA-256, the truncated variants use different initial hash values. sha512(x).substring(0, 96) !== sha384(x). Always compute SHA-384 specifically.
    • UTF-8 encoding before hashing. Same input, different encoding, different hash. Use UTF-8.
    • Don’t use for password storage. SHA-384 is too fast — use bcrypt / scrypt / argon2id for passwords.
    • HMAC-SHA-384 has different block size. SHA-384 / SHA-512 use 1024-bit (128-byte) blocks; SHA-256 uses 512-bit (64-byte) blocks. HMAC implementations need to use the matching block size — common bug in hand-rolled HMAC code.
    • Length-extension affects bare SHA-384 too. Use HMAC, not sha384(secret || data).
    • Some old systems don’t ship SHA-384. Older PHP, older Java, very old C libraries may lack SHA-384. Check support before specifying.

    When NOT to use SHA-384

    For everyday integrity checks (file checksums, deterministic IDs, message integrity in non-compliance contexts), SHA-256 is the right default — universally supported, smaller output, well-known. For password storage: use bcrypt / scrypt / argon2id; never plain SHA-384. For the longest possible security margin in archive integrity: SHA-512 (full output, same algorithm internally). For TLS 1.3 cipher suite selection: don’t manually pick — let the protocol negotiate. Use SHA-384 specifically when a spec mandates it.

    Frequently asked questions

    Is SHA-384 stronger than SHA-256?

    Yes — 192-bit collision resistance vs SHA-256’s 128-bit. Both are far beyond what’s brute-forceable today; SHA-384 matters when compliance frameworks demand the higher security level (NSA Suite B / CNSA, certain financial standards).

    Why is SHA-384 sometimes faster than SHA-256?

    SHA-384 uses the SHA-512 compression function, which operates on 64-bit words. On 64-bit CPUs each word fits a single register, giving SHA-384 / SHA-512 a 30–50% throughput advantage over SHA-256. On 32-bit hardware (rare in 2026) the trade reverses.

    Is SHA-384 just truncated SHA-512?

    Same compression function, different initial hash values (IVs). Truncating SHA-512 to 96 hex characters does NOT produce the SHA-384 hash. Always compute SHA-384 specifically.

    Should I use SHA-384 or SHA-512 for new code?

    Without a specific compliance reason, SHA-256 is the default. If you need 192-bit collision resistance, SHA-384. If you need 256-bit, SHA-512. Don’t pick SHA-384 over SHA-512 for marginal output-size reasons — both run the same internal work.

    Is my input uploaded?

    No. The generator runs the browser’s native SubtleCrypto.digest API. Text and files are processed locally — never sent to our servers.

    What’s HMAC-SHA-384 and when is it used?

    HMAC-SHA-384 is a keyed hash combining a secret key with the SHA-384 algorithm. Used for message authentication where you need to verify both data integrity and that the sender knew the key. Common in JWT signatures (JOSE algorithm HS384) and AWS Signature Version 4 for high-assurance API calls.

    Related tools and guides

     

  • CSS Toggle Switch Generator: iOS-Style Switches [2026]

    CSS Toggle Switch Generator: iOS-Style Switches [2026]

    TL;DR: A CSS toggle switch is the iOS-style “slider” UI for binary on/off settings. Built around a hidden native checkbox (for accessibility), with a custom-styled track and thumb that animates between off and on positions. Different from a checkbox visually, but semantically the same. Use switches for “settings that take effect immediately” (notifications on/off, dark mode); use checkboxes for forms with multi-select. Our free CSS switch generator ships 12+ presets — iOS, Material, brutalist — with full keyboard / screen-reader support.

    The toggle switch became the standard UI element for boolean settings around 2010 when iOS popularised it on iPhone. Compared to a checkbox, the switch communicates “this setting takes effect right now” rather than “this is part of a form”. By 2026, every settings screen uses switches; checkboxes are reserved for forms with multiple options to select.

    The implementation challenge: keep keyboard support, screen-reader announcements, and form behaviour while replacing the visual entirely. The pattern: a native <input type="checkbox"> hidden visually but kept in the DOM, plus a CSS-styled track and thumb that respond to :checked. Add ARIA role="switch" for the correct screen-reader announcement (“switch, on” vs “checkbox, checked”), and you have a switch that’s accessible by default. Our CSS switch generator outputs this pattern with 12+ visual presets.

    Switch vs checkbox — when to use which

    Use case Switch Checkbox
    Settings that change immediately (notifications) Yes No
    Form with submit button (newsletter signup) No Yes
    Multi-select filter No Yes
    Dark mode toggle Yes No
    Accept terms of service No (it’s a form input) Yes
    Visibility setting (public / private) Yes (immediate effect) No

    Rule: switch = immediate-effect binary; checkbox = form input.

    The accessible CSS switch pattern

    /* HTML: native input, ARIA role */
    <label class="switch">
      <input type="checkbox" role="switch">
      <span class="track"></span>
    </label>
    
    /* CSS: hide native input, style the track */
    .switch input {
      position: absolute;
      opacity: 0;
      pointer-events: none;
    }
    
    .switch .track {
      display: inline-block;
      width: 44px;
      height: 24px;
      background: #d0d5dd;
      border-radius: 999px;
      position: relative;
      transition: background 200ms;
      cursor: pointer;
    }
    
    .switch .track::after {
      content: "";
      position: absolute;
      top: 2px;
      left: 2px;
      width: 20px;
      height: 20px;
      background: white;
      border-radius: 50%;
      transition: transform 200ms;
      box-shadow: 0 2px 4px rgba(0, 0, 0, 0.2);
    }
    
    .switch input:checked + .track {
      background: #635BFF;
    }
    
    .switch input:checked + .track::after {
      transform: translateX(20px);
    }
    
    .switch input:focus-visible + .track {
      outline: 2px solid #635BFF;
      outline-offset: 2px;
    }

    The native input is hidden visually but kept in the DOM — keyboard Space still toggles it, screen readers announce “switch, on / off” because of role="switch", and form submission still works.

    Visual presets

    • iOS Default: rounded pill, white thumb, blue/green when on. Apple’s HIG style.
    • Material Design: wider thumb, slightly different proportions, M3 colour tokens.
    • Brutalist: sharp rectangular track, no border-radius, bold colours.
    • Outlined: visible border on the track, transparent track when off.
    • Squared: slight border-radius (8px) instead of pill — modern web app style.
    • Compact: 32×16 (smaller than default 44×24) for dense UI.
    • Animated icon: sun/moon icons fade in the thumb based on state.
    • 5 more presets in the gallery.

    How to generate a CSS switch

    1. Open the CSS switch generator
    2. Pick a preset (iOS, Material, brutalist, etc.)
    3. Adjust track color, thumb color, animation duration, and switch size
    4. Click Copy CSS + HTML for a complete drop-in component

    Common gotchas

    • Don’t replace the input with a div. Common bug: hide the input entirely, replace with custom div. Loses keyboard support, screen-reader announcements, form submission. Always keep the native input and style around it.
    • role=”switch” on input vs label. ARIA role="switch" goes on the input, not the wrapping label. Screen readers announce “switch, on / off” instead of “checkbox, checked / unchecked”.
    • :focus-visible is mandatory. Use :focus-visible for the focus ring, not :focus — otherwise every click shows the focus ring, looks bad. Universal browser support in 2026.
    • Don’t trap focus inside the switch. A common bug: pointer-events: none on the input but no clear focusable target. Result: keyboard users can’t tab to the switch. Verify keyboard navigation across all switches.
    • Animation can be disabled. Respect @media (prefers-reduced-motion: reduce) and skip the thumb-slide animation for users with vestibular disorders. Toggle still works; just snaps instantly.
    • Don’t make switches too small. Minimum touch target is 44×44 px (Apple HIG) or 48×48 px (Material). The visible track can be smaller, but the clickable area must hit minimum.

    When NOT to use a CSS switch

    For form inputs that submit with a button (newsletter signup, accept-terms, multi-select filters), use a checkbox — switches imply immediate effect. For binary settings that take significant action (deleting account, publishing content), use a button with confirmation, not a switch — accidental switch toggles are too easy. For three-way state (off / on / mixed), use a button group or radio. For very dense settings panels (10+ switches per screen), consider grouped settings with subheadings rather than a flat wall of switches.

    Frequently asked questions

    Switch or checkbox — what’s the difference?

    Semantically the same (binary state); visually and behaviourally different. Switch = immediate-effect setting (notifications on/off). Checkbox = form input that requires submit. Native HTML doesn’t have a switch element — use a checkbox + ARIA role="switch".

    Will custom CSS break accessibility?

    Not if you keep the native input. Hide it visually with positioning + opacity, but leave it in the DOM. Keyboard, screen reader, form submission all work. Don’t replace the input with a div.

    Is role=”switch” supported by screen readers?

    Yes — VoiceOver (iOS / macOS), TalkBack (Android), NVDA, JAWS all announce “switch, on” or “switch, off”. Older readers fall back to “checkbox, checked / unchecked”, which is acceptable.

    How do I prevent accidental toggles?

    For high-stakes actions, use a button with confirmation rather than a switch. For sensitive settings (e.g., “make profile public”), pair the switch with a confirmation modal on first use. Switches are designed for fast, reversible toggles — high-stakes actions deserve more friction.

    Is my data uploaded?

    No. The generator runs in your browser. Settings, the live preview, and the exported CSS stay on your device.

    Can I animate the switch differently?

    Yes — pick a “Bounce” or “Snap” preset, or write your own cubic-bezier() easing. Smooth slide is the default; bouncy animations feel playful but should respect prefers-reduced-motion.

    Related tools and guides

     

  • CSS Glitch Effect: Cyberpunk Text Animation [2026]

    CSS Glitch Effect: Cyberpunk Text Animation [2026]

    TL;DR: A CSS glitch effect creates the cyberpunk RGB-split look — text rendered three times in red, cyan, and white, with each layer offset slightly and animated to create a “broken display” feel. Used for hero text on cyberpunk-themed sites, gaming UIs, error states, and brand identities that want a “glitchy” aesthetic. Our free CSS glitch generator ships 8+ presets, animation controls, and respects prefers-reduced-motion for accessibility.

    The “glitch text” aesthetic peaked in the late 2010s alongside cyberpunk’s design revival — Cyberpunk 2077 marketing, gaming UIs, vaporwave Tumblr blogs, hacker-aesthetic indie sites all leaned on RGB-split text. The technique mimics a CRT display with misaligned colour channels. The CSS implementation: render the text three times — one layer in red shifted left, one in cyan shifted right, one in white at original position — then animate the offsets randomly to create the “stuttering” feel.

    Our CSS glitch effect generator ships 8+ tested presets ranging from subtle (a steady RGB split with no animation) to chaotic (rapidly stuttering text with clip-path slices). All output is pure CSS with no JavaScript dependency, and includes a @media (prefers-reduced-motion) branch that disables the animation for accessibility-sensitive users. This guide covers the technique, the accessibility considerations, and when the glitch aesthetic is the wrong choice.

    Glitch effect anatomy

    The classic RGB-split glitch uses CSS pseudo-elements and absolute positioning:

    .glitch {
      position: relative;
      color: white;
      font-weight: 700;
    }
    .glitch::before,
    .glitch::after {
      content: attr(data-text);
      position: absolute;
      top: 0;
      left: 0;
      width: 100%;
      height: 100%;
    }
    .glitch::before {
      color: #ff0080;
      transform: translate(-2px, 0);
      mix-blend-mode: screen;
      animation: glitch-1 2s infinite;
    }
    .glitch::after {
      color: #00fff0;
      transform: translate(2px, 0);
      mix-blend-mode: screen;
      animation: glitch-2 2s infinite;
    }
    @keyframes glitch-1 {
      0%, 100% { transform: translate(-2px, 0); }
      20% { transform: translate(-3px, 1px); }
      40% { transform: translate(-1px, -1px); }
    }
    @keyframes glitch-2 {
      0%, 100% { transform: translate(2px, 0); }
      20% { transform: translate(3px, -1px); }
      40% { transform: translate(1px, 1px); }
    }
    @media (prefers-reduced-motion: reduce) {
      .glitch::before, .glitch::after { animation: none; }
    }

    The HTML uses data-text="GLITCH" on the element and the pseudo-elements pull that via content: attr(data-text). This avoids duplicating text in the DOM (which would break screen readers). Result: visually three layers of text; semantically just one.

    Glitch presets and what each looks like

    Preset Style Best for
    Static RGB-split No animation, just colour offsets Logo / wordmark with subtle effect
    Smooth glitch 2s sine-wave animation Hero headlines, soft cyberpunk
    Stuttering Discrete jumps with steps() Aggressive cyberpunk aesthetic
    Slice glitch clip-path random horizontal slices Error states, dramatic effect
    Color burst Hue-rotate animation on top Vaporwave, retro-tech
    Hover-only Glitch activates on hover Buttons, navigation links

    How to generate a glitch effect

    1. Open the CSS glitch effect generator
    2. Type the text you want to glitch (default: “GLITCH”)
    3. Pick a preset (static, smooth, stuttering, slice, etc.)
    4. Adjust intensity, speed, and the two RGB-split colours
    5. Click Copy CSS + HTML for a complete drop-in component

    Accessibility — glitch effects can cause harm

    Animated glitch effects can trigger problems for users with vestibular disorders, photosensitive epilepsy, and cognitive disabilities. Build them carefully:

    • Always include @media (prefers-reduced-motion: reduce). Disable animation entirely for users who set this preference. Keep the static colour offset (which is harmless).
    • Avoid rapid flashing. WCAG 2.1 prohibits content that flashes more than 3 times per second over an area larger than ~25% of the viewport. Stuttering glitch animations risk crossing this — keep frame jumps below 3/second or limit to small text areas.
    • Use aria-hidden on pseudo-elements. The duplicated text in pseudo-elements is decorative — screen readers shouldn’t read it three times. ::before and ::after are excluded from accessibility tree by default.
    • High contrast underneath. The base text colour must meet WCAG contrast against the background (4.5:1 for body, 3:1 for large text). The RGB-split layers are decoration; readability comes from the base.
    • Don’t glitch entire paragraphs. Reserve the effect for headlines, single words, or short labels. A glitching paragraph of body text is unreadable.

    Common gotchas

    • Pseudo-elements need data-text or duplicate content. If you skip data-text="GLITCH" and try to use a CSS variable, browsers don’t support content: var(--text) as text content. Use data-text + attr().
    • mix-blend-mode requires a stacking context. The RGB-split layers blend correctly only when their parent has its own stacking context. If colours look wrong, add position: relative; isolation: isolate; to the parent.
    • Animation easing matters. Smooth easing (cubic-bezier) produces a “vibrating” feel; steps(N) easing produces discrete glitchy jumps. Match easing to the aesthetic.
    • Custom colours must contrast. Pure red and pure cyan on white text reads as glitch; muted reds and cyans look like a printing error. Use saturated complementary colours.
    • Hover-only is best for navigation. Always-animated text in nav menus distracts from page content. Reserve hover-only glitch for interactive elements; full animation for hero headlines.
    • SEO impact. Glitched text is fully indexed (the base text is real DOM content). Pseudo-element duplication doesn’t pollute the index — search engines ignore ::before / ::after content.

    When NOT to use a glitch effect

    For text that needs to communicate clearly (body content, instructions, error messages), the glitch aesthetic interferes with readability. For brands targeting accessibility-conscious audiences (healthcare, education, government), the effect can be off-brand. For long-running UIs (dashboards, settings panels) where the same animation plays for hours, it gets distracting. For sites in regulated industries (financial, medical) where seriousness matters, choose calmer typography. The glitch effect is for hero moments — short, attention-grabbing, decorative — not for everyday UI.

    Frequently asked questions

    Will the glitch effect work in all browsers?

    Yes — the technique uses CSS pseudo-elements, transforms, and animations, all of which have been universally supported since 2015. mix-blend-mode is supported in Chrome 41+, Firefox 32+, Safari 8+. Even mobile browsers handle it cleanly.

    Can I disable the animation for accessibility?

    Yes — our generated CSS includes a @media (prefers-reduced-motion: reduce) branch that turns off the animation. Users who set this OS preference get the static RGB split without movement. Always include this; never assume motion is universally welcome.

    Does the glitch effect break SEO?

    No. The base text is real DOM content, fully indexed. Pseudo-element duplication via data-text + attr() doesn’t pollute the index — search engines ignore generated content.

    Can I use this on more than one element per page?

    Yes — but be conservative. Multiple glitching elements on the same page compete for attention and can feel chaotic. One hero glitch is plenty; reserve the effect for emphasis.

    Is my data uploaded?

    No. The generator runs in your browser. Your text, the live preview, and the exported CSS stay on your device.

    How do I customise the glitch colours?

    Pick any two complementary colours for the RGB-split layers. The defaults (pink-red #ff0080 and cyan #00fff0) are the cyberpunk classic. For brand-on-brand effects, use your brand’s accent colours — but verify they’re saturated enough to read as “glitch” rather than “blur”.

    Related tools and guides

     

  • Twitter / X Ad Revenue Generator: Meme Mockup [2026]

    Twitter / X Ad Revenue Generator: Meme Mockup [2026]

    TL;DR: A Twitter / X ad revenue generator builds a mock screenshot of the X creator-payout dashboard — the dark-themed card showing your last revenue payment in dollars. The output is for memes, jokes, comedic posts, course content, or social commentary about the creator-monetisation economy. Our free X ad revenue mockup tool renders the dashboard chrome accurately with custom amounts and impressions counts. Browser-only and clearly intended for humorous use, not fraud.

    X’s creator-monetisation programme (launched July 2023, formerly “Ad Revenue Sharing”) pays verified accounts a share of ad revenue from impressions on their replies. Payout screenshots became a popular meme genre on the platform itself — creators humble-bragging modest amounts, satirists posting absurd figures, marketers using mock dashboards in tutorials about creator economy. The actual dashboard UI is dark-mode by default, with a large dollar figure as the hero stat.

    Our X ad revenue generator recreates the dashboard’s visual layout — large amount, “Last payout” label, impressions count below — at the actual X-platform screen resolution. Customise the dollar amount, time period, impressions count, and verification status. Browser-only — your inputs never leave your device. This guide explains the legitimate uses, the legal lines, and why the tool exists at all (memes, mostly).

    Legitimate uses

    Use case OK? Notes
    Comedic meme post Yes Clearly humour, no deception
    Course / tutorial about creator economy Yes Educational, mockup labelled
    Slide presentation about social monetisation Yes Mock data in business context
    Social commentary / satire Yes Protected speech in most jurisdictions
    “Look how much I made!” deception No Misleading; can be fraud in commerce contexts
    “Course you can earn $50K/month” sales tactic No FTC deceptive-marketing violation
    Tax / income verification No Document fraud — illegal everywhere

    Rule: humour, education, and clearly-labeled mockups are fine. Anything that misleads someone about real income — especially in commerce, finance, or legal contexts — is fraud regardless of the tool used.

    Why this tool exists

    The “X ad revenue meme” became a recognisable format in late 2023 as creators started posting their first payouts. The genre includes:

    • Humble-brag screenshots (“not retiring on this”)
    • Satirical “$0.00” posts mocking the program
    • Ridiculous fake figures ($1,000,000) for comedic exaggeration
    • Comparison posts (“creator-payout from each platform” infographics)
    • “Ad revenue from a single tweet” comedic posts

    Mockup tools fit naturally — making the meme without screenshotting your actual dashboard avoids exposing real account details, real payout amounts, or other personal financial information. For comedy and education the mockup is cleaner than a real screenshot.

    How to generate a mock revenue screenshot

    1. Open the X ad revenue generator
    2. Set the dollar amount (any value — funny large, funny small, realistic)
    3. Pick the time period label (“Last 28 days”, “Yesterday’s payout”, custom)
    4. Set the impressions count, monthly views, or engagement metric
    5. Toggle dark / light mode to match X’s current default
    6. Click Export for PNG ready to repost

    The dashboard chrome we mimic

    X’s creator dashboard uses a small set of consistent design elements:

    • Background: #0F1419 (dark mode default) or #FFFFFF (light)
    • Card border: #2F3336 (dark) or #EFF3F4 (light)
    • Hero amount: 44px+ bold weight, white in dark mode
    • Label: 13px #71767B (dark) or #536471 (light), all-caps font weight 700
    • Positive change indicator: #00BA7C green with up arrow
    • Sub-stats card: #16181C background, #71767B labels, white values

    Our generator outputs all this faithfully so the mockup reads as “real X dashboard” at a glance.

    Common gotchas

    • X’s dashboard UI changes. Meta updates the design every few months — colours shift, spacing adjusts, new metrics appear. Our generator captures the late-2024 / 2025 design; older mockups look outdated.
    • Don’t include real handles. If you compose a mockup with someone else’s @username and a fake revenue number, that’s defamation territory. Use generic placeholder handles or your own.
    • Watermark for clarity. For high-visibility memes, consider adding a small “MOCKUP” or “FAKE” watermark in a corner. It doesn’t hurt the joke and makes intent crystal-clear if the image escapes its original context.
    • Currency formatting matters. X displays USD in most regions; non-US users sometimes see local currencies. Pick the format that matches your audience for authenticity.
    • Don’t use real payment dates / months. If you generate a mockup that says “October 2025 payout” with a specific real-account amount, you’re claiming a real payout occurred — bigger legal risk than abstract numbers.
    • Trademark caution. X’s logo and dashboard layout are Meta-owned trademarks. Using them in marketing materials (commercial advertising, paid promotions) without licensing is infringement. Comedy, satire, and editorial use generally fall under fair use; commercial use does not.

    When NOT to use this tool

    For real creator-payout reporting (tax forms, grant applications, sponsorship pitches with verified income), use real screenshots from your actual dashboard — never a mockup. For platform-criticism content, screenshots of real numbers (with personal info redacted) are more credible than fakes. For client deliverables claiming “this is what your account will earn”, any mock revenue figure is misleading marketing — show real estimates from your campaign data instead. The tool exists for humour and education; using it commercially in revenue-claim contexts crosses the line.

    Frequently asked questions

    Is this for real?

    No — entirely fake. The output is a mock screenshot for memes, comedy, education, and design mockups. Don’t pass it off as a real payout; that’s misleading and can be illegal in commerce contexts.

    Will the mockup look exactly like X’s dashboard?

    Visually similar but not pixel-exact. We match colours, fonts, and layout to within a few percent of the real UI. X updates the design periodically; older mockups can look slightly off compared to the current dashboard.

    Can I use this commercially?

    For editorial use (blog posts about the creator economy, slides, comedy content): yes. For paid advertising or commercial work: trademark issues — X’s UI is Meta-owned. Get licensing or stick to clearly-labeled satire / commentary.

    Why include impressions and other stats?

    Real payout screenshots include impression counts, engagement rates, etc. Including them in the mockup makes the joke (or educational example) more recognisable.

    Is my data uploaded?

    No. The generator runs in your browser. Your inputs and the exported PNG stay on your device.

    Can I add a watermark to make it clearly fake?

    Yes — toggle “Add MOCKUP watermark” in the settings. Useful for memes shared in contexts where the audience might miss the joke and assume it’s real.

    Related tools and guides

     

  • SVG Blob Generator: Random Organic Shapes [2026]

    SVG Blob Generator: Random Organic Shapes [2026]

    TL;DR: An SVG blob generator creates organic, asymmetric shapes — like rounded amoeba silhouettes — using randomised cubic Bezier curves around a circle. Used as decorative backgrounds, hero accents, sticker-style highlights, and avatar masks. Our free SVG blob generator ships a complexity slider, randomness control, gradient fills, and a seed value so you can re-generate the exact same blob later — plus PNG export with transparent background.

    Blobs are the visual mascot of late-2010s design — the Stripe, Notion, and Headspace school of organic shapes that fill awkward white space without looking like clip art. They work because the eye reads them as friendly and distinct from the rectangles that make up most of a UI. The trick is producing random-but-not-too-random curves: too uniform and the blob looks like a cookie-cutter circle; too chaotic and it looks like an inkblot.

    Our SVG blob generator uses a noise-perturbed circle algorithm — start with N evenly-spaced points around a circle, perturb each radius by a controlled amount of noise, and connect the points with smooth cubic Bezier curves. Adjust complexity (number of points, 3 to 12) and randomness (how much each point can move). Lock a seed value to reproduce the exact shape, or shuffle for a fresh variation. Outputs SVG (preferred for scaling) or PNG with transparent background.

    When blobs work — and when they don’t

    Use case Blob OK? Notes
    Hero section accent / background shape Yes The classic 2018-2024 Stripe / Notion look
    Decorative backdrop behind text Yes (with low opacity) Keep contrast above WCAG threshold
    Avatar mask Yes Used as clip-path: path() for image cropping
    Brand logo No Random shapes can’t be reproduced consistently
    Icon set No Use shape primitives or hand-drawn SVGs
    Fintech / serious B2B UI Maybe Trends suggest the look is fading — verify against your brand

    How blob shapes are generated (the algorithm)

    The simplest blob algorithm: pick N points evenly around a circle (e.g., N=8 means one point every 45°), add or subtract a random amount from each point’s radius (e.g., ±15%), then connect the points with a smooth Catmull-Rom or cubic Bezier spline. The result is a closed organic shape.

    Two parameters control the look:

    • Complexity (point count): 3–4 produces simple organic shapes; 6–8 the typical “blob” appearance; 10–12 starts to look bumpy. Higher counts approach a circle.
    • Randomness (radius variance): 0% returns a perfect circle; 15% gives the typical Stripe-style blob; 50%+ produces dramatic, almost star-like shapes; 80%+ gets weird.

    The “seed” is the random number generator initial value. Same seed + same parameters always produces the same blob — useful for reproducible designs and storing a specific shape in a stylesheet.

    How to generate a blob in your browser

    1. Open the SVG blob generator
    2. Adjust complexity (points), randomness (variance), and size
    3. Pick fill — solid colour, linear gradient, or radial gradient
    4. Click Shuffle for a new random shape, or paste a seed string for a specific one
    5. Click Copy SVG for inline use, Download SVG for asset library, or Download PNG for legacy systems

    SVG output anatomy — what you’ll paste

    <svg viewBox="0 0 200 200" xmlns="http://www.w3.org/2000/svg">
      <path
        d="M150,100 C170,140 130,180 100,170 C70,180 30,150 30,100 C20,60 60,30 100,30 C140,20 160,60 150,100 Z"
        fill="#635BFF"
      />
    </svg>

    The viewBox="0 0 200 200" defines a coordinate system; the actual rendered size is set by CSS or the width/height attributes. Inline the SVG to style the blob with CSS variables, or reference an external file via <img src="blob.svg">.

    Common gotchas

    • Don’t animate blob shape directly. CSS animation between two SVG paths needs equal point counts; otherwise the morph fails or looks broken. Use the same complexity for the start and end blob, only varying the seed.
    • Fill colour vs stroke colour. Most decorative blobs use only fill (no border). If you add a stroke, the path must be closed (ending in Z) — the generator handles this, but custom-edited blobs may render with a thin gap.
    • SVG sizing pitfalls. Set width and height via CSS (.blob { width: 100%; height: auto; }) — hard-coded width/height attributes don’t scale with parent containers.
    • Gradients need <defs>. Linear and radial gradients in SVG live inside a <defs> element and reference an ID. Generated SVG includes the defs — but if you copy only the path and forget the gradient definition, the blob renders solid black.
    • Same seed across browsers. JavaScript’s Math.random() isn’t seeded by default, so two browsers running the same generator can produce different blobs. We use a seedable PRNG (xoroshiro128+) for reproducibility.
    • Blob trends fade. The blob aesthetic peaked around 2020. By 2026 some brands are returning to grids, geometric patterns, or gradient meshes. Don’t blob everything — use sparingly as one design element among many.

    When NOT to use a blob

    For a brand identity (logo, mark, lockup), don’t use random blobs — your brand needs a consistent shape that can be reproduced exactly across business cards, app icons, billboards, and embroidery. For functional UI shapes (modal corners, button radii, container shapes), use plain border-radius or clip-path with named values — blobs are too distracting for primary UI elements. For animations between many shapes, use a dedicated motion library (Framer Motion, GSAP) with proper SVG morph plugins. For data visualisation, blobs are decoration, not data.

    Frequently asked questions

    Can I edit the blob after generating?

    Yes — the SVG path is just a string of cubic Bezier commands. Edit the d attribute manually for fine-tuning, or import the SVG into Figma / Illustrator / Inkscape for visual editing. To re-randomise within the generator, change the seed.

    Will the same seed produce the same blob across browsers?

    Yes — we use a deterministic PRNG (xoroshiro128+), so the same seed and same parameters produce identical SVG everywhere. Useful for reproducible designs.

    Can I animate between two blobs?

    Yes, but both blobs must have the same point count for smooth interpolation. Generate both with the same complexity setting and only change the seed; the animator can morph between the two paths. CSS path animations or libraries like GSAP MorphSVG handle this.

    Should I use SVG or PNG?

    SVG for web — vector scales without loss, has CSS-controllable fill, and is tiny (often under 1 KB). PNG for legacy systems that don’t render SVG (some older email clients, very old CMS plugins). PNG output is rasterised at 2× resolution by default for retina displays.

    Is my data uploaded?

    No. The generator runs in your browser. The blob shape, seed, and exported SVG/PNG never leave your device.

    Can I use blobs in print or for stickers?

    Yes — SVG scales infinitely, perfect for stickers, business cards, or large-format print. Convert to PDF or AI in your design tool of choice; the source SVG paths are widely supported.

    Related tools and guides

     

  • Open Graph Meta Generator: Build OG & Twitter Tags [2026]

    Open Graph Meta Generator: Build OG & Twitter Tags [2026]

    TL;DR: Open Graph (OG) tags are <meta> tags in your HTML <head> that tell Facebook, LinkedIn, X/Twitter, Slack, Discord, and iMessage how to render your link as a preview card. The 4 required tags are og:title, og:description, og:image, and og:url. Our free OG meta generator builds the full tag block plus Twitter Card variants and shows a live preview of how your link will look on every major platform.

    Every link shared in 2026 — on Slack, in a Discord thread, in an iMessage, pinned to a Facebook page, posted on LinkedIn — gets unfurled into a preview card. That card is built from Open Graph meta tags published by Facebook in 2010 and now treated as the de facto standard for the web. Get them right and your link gets a clickable image, branded title, and value-prop description. Get them wrong and your link shows up as a bare URL with no card, often pulling a random image from the page or no image at all.

    Our Open Graph meta generator outputs the full tag block (OG + Twitter Card + iMessage Smart App Banner support), shows a live render in 5 platform preview frames, and validates image dimensions against each platform’s spec. This guide covers every required and optional tag, the image dimensions that actually matter in 2026, and the gotchas that cause perfectly-tagged pages to render with no card at all.

    The 4 required tags and 5 you should always add

    Tag Required? Notes
    og:title Required ≤60 chars (truncated by Facebook on mobile around 65)
    og:description Required 155–200 chars; truncated around 200 on most platforms
    og:image Required 1200×630 PNG/JPG, <5 MB; absolute https URL
    og:url Required Canonical URL — ensures dedupe across platforms
    og:type Recommended website, article, video.movie, profile
    og:site_name Recommended Brand name shown above title on Facebook
    og:image:alt Recommended Alt text for screen readers — accessibility win
    twitter:card Recommended summary_large_image for full-bleed preview
    twitter:site Optional Your @handle for attribution analytics

    Image dimensions that actually render correctly

    Every platform has its own crop box. Use 1200×630 px (1.91:1) as your canonical size — it works everywhere as a “summary large image”. File should be PNG or JPG, under 5 MB. Below 600×315 will render as a thumbnail rather than a full card on Facebook.

    • Facebook / LinkedIn: 1200×630, full-bleed
    • X / Twitter (summary_large_image): 1200×600 minimum, crops to 2:1
    • WhatsApp: minimum 300×200, square crop
    • Slack / Discord: respects original; 1200×630 is safe
    • iMessage: uses og:image, square-crops aggressively — keep important content centred

    Keep critical text (logo, headline) within the centre 1200×450 zone so square crops don’t decapitate it.

    How to generate Open Graph tags for any page

    1. Open the Open Graph generator
    2. Fill in title, description, canonical URL, image URL, and site name
    3. Pick the og:type (most pages: website; blog posts: article)
    4. Watch the live preview update in 5 platform frames
    5. Click Copy meta block — paste into the <head> of your HTML before </head>
    6. Validate with the Facebook Sharing Debugger after publishing

    The exact tag block our generator produces

    For a typical blog post the generator outputs about 14 tags. The structure looks like this (real values substituted from your inputs):

    <meta property="og:title" content="Open Graph Meta Generator [2026]">
    <meta property="og:description" content="Generate OG and Twitter Card tags...">
    <meta property="og:image" content="https://simpletool.io/og/og-generator.png">
    <meta property="og:image:width" content="1200">
    <meta property="og:image:height" content="630">
    <meta property="og:image:alt" content="Open Graph generator preview">
    <meta property="og:url" content="https://simpletool.io/tools/open-graph-meta-generator/">
    <meta property="og:type" content="website">
    <meta property="og:site_name" content="simpletool.io">
    <meta name="twitter:card" content="summary_large_image">
    <meta name="twitter:title" content="Open Graph Meta Generator [2026]">
    <meta name="twitter:description" content="Generate OG and Twitter Card tags...">
    <meta name="twitter:image" content="https://simpletool.io/og/og-generator.png">
    <meta name="twitter:image:alt" content="Open Graph generator preview">

    Common gotchas

    • Facebook caches your tags for ~30 days. If you change og:image, the old image keeps showing. Force a refresh with the Sharing Debugger by clicking “Scrape Again” — until you do, every share stays stuck on the old card.
    • Relative image URLs silently fail. og:image must be an absolute URL starting with https://. /og/image.png is treated as missing by every parser.
    • Slack and Discord ignore some Twitter tags. Both prefer og: tags first and only fall back to twitter:. Always set both, don’t rely on Twitter-only tags.
    • WebP and AVIF are widely supported now — but Facebook still occasionally renders them as a broken image on iOS Messenger. Use PNG/JPG for the og:image; serve modern formats elsewhere on your page.
    • X/Twitter dropped the twitter:card requirement in 2024 — if you only set OG tags, X auto-detects them. But summary_large_image still controls whether the image renders full-bleed or thumbnail-with-text-beside.
    • Bots may not execute JavaScript. Tags injected after page load (via React/Vue without SSR) are invisible to most scrapers. OG tags must be in the initial HTML response.

    When NOT to use a generator

    If your CMS already produces OG tags (WordPress + Yoast/RankMath, Shopify, Webflow, Next.js with the Metadata API), do not paste a second block on top — duplicate tags cause unpredictable rendering. Instead, edit the values inside your CMS or framework. A generator is for static sites you control by hand, custom landing pages outside your CMS, or one-off pages where you need to override the inherited template.

    Frequently asked questions

    Do I need both Open Graph and Twitter Card tags?

    No, but it is the safest approach. Modern X and most aggregators will fall back to OG tags if Twitter-specific tags are missing. Set both for maximum coverage; the cost is 4 extra meta tags. The most common pattern is full OG + a single twitter:card=summary_large_image declaration.

    Why doesn’t my Facebook preview update after I changed the image?

    Facebook caches your og:image for roughly 30 days. Open the Sharing Debugger, paste your URL, and click Scrape Again. The cache clears immediately and any future shares pick up the new image. LinkedIn has a similar tool at Post Inspector.

    What’s the right size for og:image in 2026?

    1200×630 px (1.91:1 ratio), under 5 MB, PNG or JPG, hosted on https. This works on Facebook, LinkedIn, X (summary_large_image), Slack, Discord, and most aggregators. Keep critical content within the centre 1200×450 zone for platforms that crop to square.

    Can I generate OG tags for a Next.js or React app?

    Yes — but you should use the framework’s built-in metadata API rather than inject tags client-side. Next.js 13+ has generateMetadata in the App Router; Remix has the meta export; Nuxt has useSeoMeta(). Tags injected after JavaScript runs are invisible to most scrapers. Use this generator to compose values, then paste them into the framework’s metadata config.

    Is my data uploaded?

    No. The generator runs in your browser. We never see your title, description, or URL. The preview frames are rendered locally in your browser using the values you typed.

    What does og:type “article” change?

    It unlocks article-specific tags like article:published_time, article:author, article:section, and article:tag. Some platforms (notably Facebook News and Apple News) prioritise content with proper article tags. For a regular landing page, og:type=website is the right choice.

    Related tools and guides

     

  • Case Converter: Switch Text Between 12 Cases [2026]

    Case Converter: Switch Text Between 12 Cases [2026]

    TL;DR: A case converter switches text between UPPERCASE, lowercase, Title Case, Sentence case, and 8+ programming cases (camelCase, snake_case, kebab-case, PascalCase, CONSTANT_CASE, dot.case, path/case, Train-Case). Our free case converter handles all 12 in your browser, preserves Unicode (accented characters, emoji, non-Latin scripts), and copies output with one click.

    Switching letter case is the kind of micro-task that interrupts every writer and developer about a dozen times a week. You paste a tweet that came back UPPERCASE FROM A SCREAMING REPLY and need it back to sentence case. You name a CSS file and need my-component-styles.css instead of MyComponentStyles.css. You copy a section heading from a PDF that arrived in InCoNsiStEnT mIxEd CaSe. Word and Google Docs handle the basics (Shift+F3 in Word; Format → Text → Capitalization in Docs), but neither covers the programming cases developers reach for daily.

    Our case converter handles 12 case types in one tool, runs entirely in your browser, and gets the edge cases right (locale-aware Turkish dotted-I, ligatures, accented characters, mixed-script content). This guide explains every case, when to use which, the gotchas the obvious tools miss, and the keyboard-shortcut alternatives that fail on programming cases.

    All 12 case types and when to use each

    Case Example When to use
    UPPERCASE HELLO WORLD Headings in caps style guides, acronyms, SQL keywords
    lowercase hello world Email addresses, URLs, hashtags, casual UI labels
    Title Case Hello World From Mars Headings in AP/Chicago style; book and article titles
    Sentence case Hello world from mars Modern UI copy (Google, GitHub, Apple HIG since 2015)
    camelCase helloWorldFromMars JavaScript variables, JSON keys, Java methods
    PascalCase HelloWorldFromMars Class names (TypeScript, C#, Python), React components
    snake_case hello_world_from_mars Python variables, Ruby methods, PostgreSQL columns
    CONSTANT_CASE HELLO_WORLD_FROM_MARS Environment variables, language constants, enums
    kebab-case hello-world-from-mars URLs, CSS class names, npm packages, file names
    Train-Case Hello-World-From-Mars HTTP headers (Content-Type, X-Forwarded-For)
    dot.case hello.world.from.mars i18n keys, Java packages, namespaced configs
    iNVERSE cASE hELLO wORLD FROM mARS Fixing a CapsLock-on paragraph; novelty effect

    Title Case is the most misunderstood case

    Title Case looks simple — capitalise the important words — but the major style guides disagree on which words count. AP Style capitalises words of 4+ letters; Chicago Style capitalises 5+ letters and treats is, be, are as significant; APA Style capitalises any word longer than 3 letters; MLA Style capitalises the first and last word regardless of length, plus all major words. The result: the same headline can be valid Title Case under one guide and incorrect under another.

    Our converter follows AP Style by default (the most common guide for web headlines and blog posts) and lowercases articles (a, an, the), short prepositions (at, by, in, of, on, to, up), and short conjunctions (and, but, or, nor, for, so, yet). The first and last word are always capitalised regardless. If you need Chicago or APA, use Title Case as a starting point and manually adjust the borderline words — typically 1-2 per headline.

    How to convert text case in your browser

    1. Open the case converter
    2. Paste or type your text in the input box
    3. Click any of the 12 case buttons — output appears instantly
    4. Click Copy to copy to clipboard, or Download .txt for long text
    5. Optional: tick the AP/Chicago/MLA selector for Title Case style preference

    The Turkish dotted-I problem (and other Unicode gotchas)

    Naive case conversion (str.toUpperCase() in JavaScript without a locale) breaks for Turkish and Azerbaijani. The Turkish alphabet has two distinct letters: I (uppercase, no dot) and İ (uppercase, with dot). Lowercase i uppercases to İ; lowercase ı (dotless i) uppercases to I. Default JavaScript ignores this and produces I for both, corrupting Turkish text.

    Our converter uses toLocaleUpperCase() and toLocaleLowercase() with an auto-detected locale, so istanbulİSTANBUL in Turkish content (correct) rather than ISTANBUL (wrong). Similar fixes apply to German ß (uppercases to SS in modern Unicode, or to if you prefer the new capital eszett), Greek final sigma ς (lowercases differently from middle σ), and Lithuanian dotted letters.

    Common gotchas

    • Acronyms in Title Case. Most converters lowercase acronyms in Title Case (Nasa Launches Probe). Our tool preserves all-caps tokens of 2-5 letters as acronyms (NASA Launches Probe).
    • Hyphenated words. Title Case style guides disagree on capitalising the second part of a hyphenated word. AP capitalises both (State-Of-The-Art); Chicago lowercases the second part for closed compounds (State-of-the-art). Pick one and be consistent.
    • Programming cases on existing camelCase. Converting parseHTMLString to snake_case requires detecting the acronym boundary. Naive splitters produce parse_h_t_m_l_string; our converter outputs parse_html_string.
    • Numbers in slugs. kebab-case for URLs should preserve digit boundaries. iPhone16Pro becomes i-phone-16-pro, not iphone16pro. Search-engine readability matters.
    • Sentence case across multiple sentences. Sentence case capitalises the first letter of every sentence, not just the first letter of the whole input. Single-period detection is fragile (abbreviations like Mr. trip naive converters); our tool uses Intl.Segmenter for proper sentence boundaries.

    When NOT to use a case converter

    For one-off Microsoft Word edits, the built-in Shift+F3 cycle (Lowercase → UPPERCASE → Title Case) is faster than switching tabs. For programmatic conversion of large datasets, libraries like change-case (npm) or inflection (Python/Ruby) belong in your build pipeline, not a browser tab. And for reformatting text that needs editorial judgment — like fixing a paragraph that mixes proper nouns with sentence-case errors — a human editor will always beat any automated rule.

    Frequently asked questions

    Is the conversion case-sensitive across languages?

    Yes. Our converter uses locale-aware Unicode rules so Turkish dotted-I, German eszett, Greek final sigma, and Lithuanian dotted letters round-trip correctly. For most Latin-script content the default works; for Turkish or Azerbaijani text you can manually pick the locale to force the correct mapping.

    Does Title Case follow AP, Chicago, or MLA?

    Default is AP Style (lowercase articles, short prepositions, and short conjunctions; capitalise everything else). A dropdown lets you switch to Chicago or APA, which differ on the cutoff length for prepositions. MLA capitalises the first and last word always — our converter applies that rule under all three options.

    How do I convert camelCase to snake_case correctly?

    Paste the camelCase text and click snake_case. The converter detects boundaries on uppercase letters, preserves runs of acronyms (parseHTMLStringparse_html_string, not parse_h_t_m_l_string), and handles digit boundaries (iPhone16i_phone_16).

    What’s the difference between Title Case and Capitalized Case?

    Capitalized Case (sometimes called “Initial Caps”) capitalises the first letter of every word including articles and prepositions. Title Case follows a style guide and lowercases small words like and, the, of. Capitalized Case is rare in modern publishing; almost every editorial style uses true Title Case or sentence case.

    Is my text uploaded?

    No. The case converter runs in your browser via JavaScript. Your text is never uploaded, logged, or stored on our servers. You can verify this in your browser’s Network tab — clicking a case button generates zero outbound requests.

    Can I batch-convert a file or column of values?

    Yes. Paste any size text up to your browser’s memory limit (effectively several MB on a modern device). For each line you can convert independently by checking “Per-line” mode, useful for converting a column of CSV values without merging them into one paragraph.

    Related tools and guides

     

  • SVG to PNG Converter: Retina Export in Browser [2026]

    SVG to PNG Converter: Retina Export in Browser [2026]

    TL;DR: An SVG to PNG converter rasterises a vector SVG into a PNG image at any custom dimensions, with optional transparent or solid background. Useful when uploading to platforms that don’t accept SVG (most social media, many email clients, app stores). Our free SVG to PNG converter runs in your browser, supports custom width/height plus retina exports (1x/2x/3x), and never uploads your SVG.

    SVG is the right format for icons, logos, and any vector art that needs to scale infinitely. Browsers love SVG — small file size, perfect crispness at any zoom, CSS-themable. But not every platform accepts SVG. Instagram, X/Twitter, LinkedIn, and TikTok all reject SVG uploads. Most email clients won’t render embedded SVG. App store icon submissions require PNG. The standard fallback is to convert SVG to PNG at the right resolution before upload.

    Our SVG to PNG converter handles single SVGs and batch conversions, with custom dimension control and retina export modes. The conversion happens via the browser’s canvas API; your SVG never uploads. This guide explains the right output dimensions for common use cases, the transparency handling, and the gotchas with embedded fonts and external references in SVG files.

    Standard PNG export sizes for common use cases

    Use case Recommended PNG size
    Favicon 32×32, 192×192, 512×512 (multiple sizes for different contexts)
    App icon (iOS/Android) 1024×1024 master, downsampled to platform requirements
    Social media profile picture 400×400 (universally supported)
    Logo on website (retina) 2× the display size (e.g., 600×200 PNG for a 300×100 logo slot)
    Email signature 300×100 max (kept under 100 KB to avoid clipping)
    Print materials 300 DPI at intended print dimensions (4 in × 4 in = 1200×1200)

    How to use the browser SVG to PNG converter

    1. Open the SVG to PNG converter
    2. Drop your .svg file or paste SVG markup directly
    3. Set the output width and height (preserves aspect ratio by default)
    4. Choose background: transparent (default), white, or custom colour
    5. Optional: tick 1x / 2x / 3x to export multiple retina variants in one go
    6. Click Download. Single file or ZIP for multi-variant exports

    SVG features that may not survive conversion

    • External font references. If your SVG uses font-family: "Custom Font" and the font isn’t available, the browser substitutes a default. Either embed font data in the SVG or use <text> as outlined paths.
    • External image references. SVGs that reference external images via <image href="..."> may produce CORS errors during canvas rasterisation. Embed images as Base64 data URIs instead.
    • Filter effects. Some SVG filters (Gaussian blur, displacement maps) render slightly differently across browsers. The PNG result captures whatever the current browser produces.
    • SVG animations. SMIL or CSS animations are captured at the current frame. To export a specific animation state, pause the animation before triggering export.

    Converting in code

    // Browser (canvas)
    const img = new Image();
    img.src = "data:image/svg+xml;utf8," + encodeURIComponent(svgString);
    img.onload = () => {
      const canvas = document.createElement("canvas");
      canvas.width = 512; canvas.height = 512;
      canvas.getContext("2d").drawImage(img, 0, 0, 512, 512);
      canvas.toBlob(blob => downloadBlob(blob, "out.png"));
    };
    
    // Node.js (sharp — best quality)
    import sharp from "sharp";
    await sharp("logo.svg").resize(512, 512).png().toFile("logo.png");
    
    // Python (cairosvg)
    import cairosvg
    cairosvg.svg2png(url="logo.svg", write_to="logo.png",
                     output_width=512, output_height=512)
    
    // CLI (rsvg-convert)
    rsvg-convert -w 512 -h 512 logo.svg -o logo.png

    Common conversion mistakes

    • Exporting at 1x for retina displays. A 300×100 logo at 1x looks blurry on retina. Always export at 2x or 3x and scale down via HTML width/height attributes.
    • Forgetting transparency. Default canvas backgrounds are white in some libraries. Verify the PNG has the transparent background you expect.
    • Tiny dimensions for app icons. Always start from a high-res master (1024×1024) and downsample to platform requirements. Upscaling small PNGs produces blurry icons.
    • Skipping background colour for printing. Print processes don’t handle transparency well; export with explicit white background for print PNGs.

    Frequently asked questions

    Why convert SVG to PNG at all?

    Many platforms reject SVG uploads — Instagram, X/Twitter, TikTok, LinkedIn for posts, most email clients, app stores. PNG is universally accepted. Convert when you need to upload your vector logo or icon to one of these platforms.

    Will the PNG be as crisp as the SVG?

    At the export resolution, yes. Below the export resolution, the browser interpolates which causes slight blur. Above, the PNG can’t add detail. Always export PNGs at 1x-3x the intended display size.

    Does the converter preserve transparency?

    Yes — by default the PNG has a transparent background. Toggle to add a solid colour (white is most common for print) when needed.

    Can I batch convert multiple SVGs?

    Yes — drop multiple SVG files. Each converts to PNG at your chosen dimensions. Result downloads as a ZIP of all PNGs.

    Is my SVG uploaded?

    No. The browser reads the SVG locally, rasterises on canvas, and offers PNG download. No network requests during conversion.

    What’s the maximum SVG complexity the converter handles?

    Limited by browser memory. Very complex SVGs (thousands of paths, large embedded images) may take 5-15 seconds to render. For production logos and icons, conversion is instant.

    Related tools and guides

     

  • Character Counter: Live Word & Letter Count [2026]

    Character Counter: Live Word & Letter Count [2026]

    TL;DR: A character counter shows how many characters, words, sentences, and paragraphs are in any text — with live limits for tweets (280), meta descriptions (155), SMS (160), and other constrained writing contexts. Our free character counter updates as you type, highlights when you cross a limit, and runs entirely in your browser.

    Writers, marketers, and students count characters constantly. Tweet limit is 280; meta description is ~155; SMS message before splitting is 160; LinkedIn post for maximum reach is ~1,300; YouTube title is 60. Almost every text-based platform imposes a length constraint that shapes what you can say. A character counter that shows the count live as you type — with the right limits for your context — turns “did I cross the limit?” guesswork into instant feedback.

    Our character counter reports characters (with and without spaces), words, sentences, paragraphs, and reading time. Hit a preset limit and the relevant counter turns red. Useful for the dozen contexts every writer juggles per week. This guide covers the standard length limits, the difference between character and letter counts, and the platform-specific gotchas (Twitter counts URLs as 23 characters; SMS uses GSM-7 vs UCS-2 character sets).

    Standard length limits across platforms

    Platform / Use Limit Notes
    Twitter / X post 280 chars (Twitter Blue: 4,000) URLs count as 23 chars regardless of length
    Meta description ~155 chars Google truncates with “…” in mobile SERP
    Page title (SEO) ~60 chars Google truncates around 600 px width
    SMS (single message) 160 chars (GSM-7) / 70 chars (UCS-2) Emoji or non-Latin chars trigger UCS-2
    LinkedIn post 3,000 chars (1,300 visible before “see more”) Algorithm rewards 1,200-2,000 char range
    Instagram caption 2,200 chars First 125 chars visible before “more”
    Facebook post 63,206 chars (effectively unlimited) First 80-130 chars before “see more”
    YouTube title 100 chars (~60 visible) CTR drops sharply past 60 visible chars
    YouTube description 5,000 chars First 100 chars visible above fold

    Character vs letter vs word — definitions matter

    • Characters (with spaces): every Unicode code point — letters, digits, punctuation, spaces, emoji, line breaks. The most common count for platforms with limits.
    • Characters (without spaces): excludes whitespace. Useful for academic word-count requirements that specify “characters not counting spaces”.
    • Letters: only alphabetic characters. Excludes digits, punctuation, spaces. Rarely a platform limit but useful for puzzle/game word work.
    • Words: sequences of non-whitespace characters separated by spaces. The standard academic and editorial unit.
    • Sentences: text segments ending in . ! ?. Useful for readability scoring (Flesch-Kincaid).
    • Paragraphs: blocks separated by blank lines. The natural editorial unit for long-form writing.

    How to use the browser character counter

    1. Open the character counter
    2. Type or paste text into the input
    3. The counter updates live: characters, words, sentences, paragraphs, reading time
    4. Pick a preset (Tweet 280, Meta 155, SMS 160) — the relevant counter shows progress and turns red when exceeded
    5. Optional: tick “Without spaces” for the alternate character count

    Reading time math

    Reading time is computed at 200-250 words per minute (the average adult reading rate for moderate-difficulty prose). Our counter uses 230 wpm. For technical writing, expect ~150 wpm; for fiction, ~280 wpm. Use the readability count as a planning tool, not a strict promise.

    Common gotchas

    • Twitter URL counting. Twitter counts every URL as 23 characters regardless of actual length. A 50-char URL costs only 23 toward your 280 limit.
    • SMS character set switching. Add one emoji to a 160-char SMS and the entire message switches from GSM-7 (160 chars / segment) to UCS-2 (70 chars / segment). The same text now requires multiple segments and costs more to send.
    • Emoji counted multiple ways. A simple smiley 😀 is 1 character in most counters but 2 UTF-16 code units. Some old systems count emoji as multiple characters.
    • Trailing whitespace. Many platforms trim trailing spaces but count them locally. Pasting “hello ” into Twitter shows as 6 chars but posts as 5.

    Frequently asked questions

    Does the counter count emoji as one or multiple characters?

    One. Modern counters (including ours) use Intl.Segmenter to count emoji as single grapheme clusters, matching how humans perceive them. Twitter, SMS, and Instagram count emoji similarly.

    Why do my Twitter character counts differ?

    Twitter counts URLs as 23 characters. Our counter reports raw character count. For a Twitter-aware count, manually subtract URL lengths and add 23 per URL.

    What’s the right meta description length for SEO?

    150-160 characters. Google truncates around 155 chars on mobile, 158 on desktop. Aim for 155 to leave a small safety buffer.

    How is reading time calculated?

    Word count divided by 230 (the standard average words-per-minute for adult readers). Technical writing reads slower (~150 wpm); fiction reads faster (~280 wpm). Use as a planning tool.

    Is my text uploaded?

    No. The counter runs in your browser via JavaScript. Text and counts stay on your device.

    Can I count characters in code or markdown?

    Yes — the counter treats all text identically regardless of format. For markdown, raw characters include the asterisks and hash marks; rendered word count would differ. The tool reports raw values.

    Related tools and guides