simpletool.io Browse tools

Blog

  • Vimeo Thumbnail Downloader: Get Every Size [2026]

    Vimeo Thumbnail Downloader: Get Every Size [2026]

    TL;DR: Vimeo generates several thumbnail sizes for every public video — typically 100×75, 200×150, 295×166, 640×360, 1280×720, and 1920×1080. Unlike YouTube, Vimeo’s URLs aren’t predictable — you have to query Vimeo’s oEmbed API to get the actual filename for a given video. Our free Vimeo thumbnail downloader hits the oEmbed endpoint, lists every available resolution, and lets you download any size with one click. Browser-only — paste a Vimeo URL, get the thumbnails.

    Vimeo creators upload custom thumbnails (or auto-generate them from a video frame). Once published, those thumbnails are accessible via Vimeo’s CDN at predictable filenames per video — but the filename pattern depends on a unique image ID Vimeo assigns at upload, not the video ID. So the path i.vimeocdn.com/video/12345_640.jpg only works if you know the image ID, which you don’t get from the video URL.

    The official path: query the oEmbed endpoint at https://vimeo.com/api/oembed.json?url=. The response includes thumbnail_url (the default size) and other metadata. From the URL you can extract the image ID, then construct URLs for all the standard resolutions. Our Vimeo thumbnail downloader automates this — paste a video URL, get a list of all available sizes with download buttons.

    Standard Vimeo thumbnail sizes

    Size suffix Dimensions Best for
    _100 100×75 Tiny inline previews, RSS feeds
    _200 200×150 Sidebar widgets, list views
    _295 295×166 Vimeo’s default embed grid size
    _640 640×360 Standard preview tile (16:9 SD)
    _1280 1280×720 HD preview, blog hero image
    _1920 1920×1080 Full-HD preview, retina hero

    Not every video has every size. Older uploads (pre-2017) sometimes max out at 1280×720; very old uploads at 640×360. The largest available size is whatever the original upload supports — Vimeo doesn’t upscale.

    How to download a Vimeo thumbnail

    1. Open the Vimeo thumbnail grabber
    2. Paste any Vimeo URL — works with public videos, channels, showcases, on-demand pages
    3. The tool calls Vimeo’s oEmbed endpoint and lists every available resolution
    4. Click any thumbnail to download as JPG
    5. Or right-click → “Copy image address” to grab the direct CDN URL for embedding

    Vimeo’s oEmbed response — what’s actually available

    The oEmbed JSON response includes more than just thumbnails:

    {
  "title": "Video Title",
  "author_name": "Creator",
  "thumbnail_url": "https://i.vimeocdn.com/video/12345_295x166.jpg",
  "thumbnail_url_with_play_button": "https://i.vimeocdn.com/filter/overlay?...",
  "duration": 256,
  "video_id": 1234567,
  "uri": "/videos/1234567"
}

    The thumbnail_url always points to one specific size (typically 295×166). To get the larger sizes, swap the suffix in the URL — _640.jpg, _1280.jpg, _1920.jpg. Our tool does this automatically and verifies each size returns a 200 response before listing it.

    YouTube vs Vimeo thumbnail patterns

    YouTube thumbnails follow a predictable URL pattern: https://img.youtube.com/vi/<video_id>/maxresdefault.jpg. Construct it from the video ID, no API call needed. Vimeo doesn’t work this way — you must query the oEmbed API to get the image ID before you can construct the thumbnail URL.

    For YouTube, see our YouTube Thumbnail Grabber; for Vimeo, this tool is the right pick.

    Common gotchas

    • Private videos return errors. oEmbed only works for public videos. Private videos (Vimeo Plus / Pro privacy settings: only me / password / domain-restricted) return a 403. There’s no public way to grab a private video’s thumbnail without an authenticated API call.
    • Showcase URLs need careful handling. A URL like vimeo.com/channels/staffpicks/1234567 requires extracting just the video ID. Our tool detects every URL format Vimeo uses.
    • Custom thumbnails take a moment to update. If a creator just uploaded a new custom thumbnail, the CDN may serve the cached old version for up to an hour. Try again later if you see a stale image.
    • Animated thumbnails aren’t available. Vimeo offers a “play button overlay” version (thumbnail_url_with_play_button) but no animated GIF thumbnail like YouTube’s hover preview. The static image is the largest you’ll get.
    • Aspect ratio is fixed at 16:9. All standard sizes are 16:9 — even if the source video is 4:3 or vertical, Vimeo letterboxes to 16:9 for thumbnail purposes. The full-resolution image always has the original aspect ratio though.
    • Rate-limit considerations. Vimeo’s oEmbed endpoint has rate limits (typically 60 requests per minute per IP). Our tool calls it on demand only — so a single user fetching one video at a time never hits the limit.

    When NOT to use this tool

    If you only need thumbnails for one video and you control the page, use Vimeo’s official embed code — the embed includes thumbnail rendering before the player loads, so no separate download is needed. For batch automation across hundreds of videos, use Vimeo’s API directly with an OAuth token (more powerful, no rate-limit concerns). For private videos, this tool can’t help — request access from the creator. For thumbnails of platforms other than Vimeo, see the YouTube Thumbnail Grabber or social media tools category.

    Frequently asked questions

    Does this work for private Vimeo videos?

    No. Vimeo’s oEmbed API only returns data for public videos. Private (Plus/Pro privacy settings) videos return a 403 error. The privacy is intentional — there’s no workaround that doesn’t involve an authenticated API call with the creator’s permission.

    Why doesn’t my Vimeo URL work?

    Three usual causes: (1) the video is private; (2) the URL is from a deleted video; (3) the URL is malformed. Try the canonical share URL from Vimeo’s “Share” button (looks like vimeo.com/1234567). If it still fails, the video is likely private.

    What’s the highest resolution available?

    Up to 1920×1080 for HD-uploaded videos. Older uploads (pre-2017) cap at 1280×720 or 640×360. Vimeo doesn’t upscale, so the highest size matches the original upload’s resolution — you can tell the original quality by what’s available.

    Can I use these thumbnails commercially?

    Thumbnails are part of the original upload, owned by the creator. Using them commercially (in your product, in advertising, in derivative works) requires the creator’s permission. For embedding the video itself with its thumbnail (as Vimeo’s embed code does), Vimeo’s terms allow this for any public video.

    Is my URL uploaded to your servers?

    Yes — to fetch the thumbnail URL we have to call Vimeo’s oEmbed API with the URL you paste. The URL goes from your browser directly to Vimeo (we use a CORS proxy or direct fetch). The thumbnails themselves are downloaded directly from Vimeo’s CDN to your browser.

    Why is Vimeo harder to grab than YouTube?

    YouTube uses predictable URL patterns based on video ID. Vimeo uses image IDs assigned at upload, separate from video IDs — so you must call the oEmbed API to map between the two. The result is the same kind of tool but with one extra API hop.

    Related tools and guides

     

  • CSS Loader Generator: 60+ Pure-CSS Spinners [2026]

    CSS Loader Generator: 60+ Pure-CSS Spinners [2026]

    TL;DR: A CSS loader (or “CSS spinner”) is an animated waiting indicator built with pure CSS — no JavaScript, no SVG sprites, no GIFs. The five common patterns are spinning circles (border + animation), bouncing dots (3-dot pulse), progress bars (animated linear-gradient), skeleton screens (pulsing rectangles representing content shape), and conic gradients (modern Chromium+ Safari). Our free CSS loader generator ships 60+ presets, lets you customise size/speed/colour, and outputs accessible CSS that respects prefers-reduced-motion.

    Adding a loading spinner used to mean dropping a 12 KB animated GIF into your project. CSS animations made it weight-zero — a few hundred bytes of CSS, GPU-accelerated rendering, instantly responsive to dark mode and theme changes. The result: every modern app uses pure-CSS loaders. The challenge: writing a smooth, accessible loader from scratch involves keyframes, timing functions, transform-origin, and accessibility considerations that aren’t obvious.

    Our CSS loader generator ships 60+ tested presets across five categories — spinning circles, dots, bars, skeleton screens, and conic-gradient loaders. Customise size, speed, colour, and stroke width with sliders. Copy production-ready CSS that includes prefers-reduced-motion handling and proper ARIA attributes. This guide covers when each loader type is appropriate, the accessibility traps, and the performance gotchas that turn a smooth spinner into a paint-thrashing battery drain.

    Five loader types and when to use each

    Type Best for Avoid when
    Spinning circle Generic “loading…” (under 1s) User waits more than 3s — feels unresponsive
    Bouncing dots Chat / typing indicators Page-level loading — too playful
    Progress bar Known-duration tasks Indeterminate progress (use indeterminate variant)
    Skeleton screen Content-heavy pages — feels faster than spinners Single-element waits — overkill
    Conic-gradient Modern, distinctive loaders IE / very old browser support required

    A canonical pure-CSS spinner

    The simplest CSS spinner is a circle with a transparent top border, rotated indefinitely. About 8 lines of CSS, GPU-accelerated, ~200 bytes minified:

    .loader {
  width: 32px;
  height: 32px;
  border: 4px solid #e0e0e0;
  border-top-color: #635BFF;
  border-radius: 50%;
  animation: spin 0.8s linear infinite;
}
@keyframes spin {
  to { transform: rotate(360deg); }
}
@media (prefers-reduced-motion: reduce) {
  .loader { animation-duration: 3s; }
}

    The reduced-motion media query slows the animation rather than stopping it — users with vestibular disorders prefer slow over absent. Stopping animations entirely can break the implied “still loading” message.

    How to build a loader in your browser

    1. Open the CSS loader generator
    2. Pick a preset from the gallery (60+ available across 5 categories)
    3. Adjust size, speed (animation duration), colour, and stroke width
    4. Watch the live preview animate in real time
    5. Click Copy CSS for production-ready code with prefers-reduced-motion handling
    6. Or click Copy as HTML+CSS for a complete drop-in component

    Accessibility — the loaders that beat off-the-shelf libraries

    Most spinners shipped on Stack Overflow and CodePen miss accessibility basics:

    • ARIA role + label. Loaders need role="status" and aria-label="Loading" so screen readers announce them. Without these, blind users have no idea anything is happening.
    • prefers-reduced-motion. Slow or pause animations for users with vestibular disorders. Don’t remove the spinner — slow it from 0.8s to 3s rotation.
    • Visible loading text. A pure visual spinner gives no information. Pair with text like “Loading”, “Saving…”, “Fetching results” — both for accessibility and to communicate context.
    • Removed from DOM when done. An invisible spinner left in the DOM still gets announced by screen readers as “loading”. Remove it or set aria-hidden="true" when complete.
    • Don’t trap focus. A loader covering the page shouldn’t trap keyboard focus inside the spinner. Either make the page scrim non-interactive or move focus to a meaningful element when loading completes.

    Our generator outputs CSS with the ARIA attributes baked in. Copy and paste — accessibility done.

    Common gotchas

    • Don’t animate top, left, or width. Layout-triggering properties cause the browser to recalculate every frame. Always animate transform and opacity for 60fps. Our presets only use those.
    • Conic gradients need fallbacks. conic-gradient() works in Chrome 69+, Safari 13+, Firefox 83+ — close to universal in 2026. For very old browsers (IE, very old Android stock browser), provide a fallback border-style spinner via @supports.
    • Skeleton screens with shimmer animation can be expensive. A full-page skeleton with 20 animated rectangles taxes mobile CPUs. Test on a low-end phone before shipping; consider a single-element pulse instead of per-element shimmer.
    • Animation timing functions matter. linear for spinners (constant rotation feels “loading”), ease-in-out for bouncing dots (more natural pulse), cubic-bezier() for character or branded loaders.
    • Don’t stack multiple loaders on one page. One global spinner is enough; multiple loaders create competing animations that distract. Use skeleton screens for multiple regions instead.
    • Border-radius doesn’t always match expected geometry. A 50% border-radius on a non-square element produces an ellipse, not a circle. Spinners need explicit equal width and height.

    When NOT to use a CSS loader

    For known-duration uploads or downloads, use a real progress bar showing percentage — much more informative than an indeterminate spinner. For sub-100ms operations, don’t show a loader at all (it’ll flash and feel jankier than no feedback). For very long operations (over 10 seconds), pair with text updates (“Uploading… 1.2 MB of 4 MB”) because a constant spinner stops feeling like progress. For complex character-style loaders (like the Discord cat or GitHub Octocat), consider an SVG or Lottie animation instead — pure CSS hits a complexity ceiling around morphing shapes.

    Frequently asked questions

    Are CSS loaders accessible to screen readers?

    Only with role="status" and aria-label. Our presets ship with both. A bare <div> with animation gives no information to assistive tech — always pair the visual with proper ARIA, plus a hidden text alternative if the loader represents a complex state.

    Do CSS loaders work on all browsers?

    Border-style spinners and bouncing-dot loaders work in every browser since IE 10. Conic-gradient loaders need Chrome 69+, Safari 13+, Firefox 83+ — universal in 2026 except for IE (retired by Microsoft in 2022). Use @supports (background: conic-gradient(red, blue)) for graceful fallback if you support IE.

    How do I respect prefers-reduced-motion?

    Add a media query that slows or replaces the animation: @media (prefers-reduced-motion: reduce) { .loader { animation-duration: 3s; } }. Don’t remove the loader entirely — users still need feedback that something is happening.

    Can I use these in React, Vue, or Svelte?

    Yes — they’re CSS-only, so framework-agnostic. Drop the CSS into a stylesheet, add the markup as a component, and apply the class. Use scoped styles in Vue/Svelte to avoid cross-component conflicts.

    Will animated loaders drain the battery?

    Properly built ones (animating only transform and opacity) are GPU-accelerated and very cheap. Layout-triggering animations (animating width or top) can drain battery. Browsers also pause animations on hidden tabs to save power; a forgotten spinner on an inactive tab won’t keep the GPU busy.

    Is my data uploaded?

    No. The generator runs entirely in your browser. Customisations and the generated CSS stay on your device.

    Related tools and guides

     

  • Google Fonts Pairing Tool: Find Heading + Body Pairs [2026]

    Google Fonts Pairing Tool: Find Heading + Body Pairs [2026]

    TL;DR: A Google Fonts pairing tool helps you pick a heading font and a body font that work well together — usually one display/serif and one neutral sans-serif. The proven principle: contrast. Pair a high-character heading (Playfair Display, Bebas Neue, Lora) with a clean body (Inter, IBM Plex Sans, Source Sans Pro). Our free Google Fonts pair finder ships 30+ curated pairs, lets you preview any combination, and copies the @import + CSS variables ready to drop in. Browser-only.

    Picking two fonts that work together is the design decision developers most often get wrong. Defaulting to “Roboto for everything” works but reads as utilitarian; picking two display fonts at random produces visual chaos. The principle that designers use: contrast — pair fonts that differ along one axis (serif vs sans-serif, high-contrast vs low-contrast, geometric vs humanist) so headings and body don’t compete for attention.

    Our Google Fonts pair finder ships 30+ tested pairs (Inter + Playfair Display, IBM Plex Sans + IBM Plex Serif, Source Sans Pro + Lora, etc.) plus a free-form mode where you can preview any two of the 1,500+ Google Fonts side-by-side. Outputs a copy-paste <link> tag for the HTML head plus CSS variables. This guide covers what makes a good pair, the four anti-patterns that always fail, and how to verify your pair works at common font sizes.

    The 6 most reliable pairing patterns

    Pattern Heading Body Feel
    Editorial Playfair Display Source Sans Pro Magazine, premium publishing
    SaaS / clean Inter Inter Modern web app — single-family is fine
    Corporate / serious IBM Plex Serif IBM Plex Sans Banking, B2B, healthcare
    Display + neutral Bebas Neue Open Sans Posters, gym, agency
    Soft serif Lora Inter Blogs, literary, gentle
    Geometric duo Poppins DM Sans Startup, tech-forward

    The contrast principle (in one sentence)

    A good pair differs noticeably along one axis but not too many. The common axes:

    • Serif vs sans-serif (Playfair + Source Sans, Lora + Inter)
    • Display vs neutral (Bebas Neue + Open Sans, Lobster + Inter)
    • High-contrast vs low-contrast stroke weight (Cormorant + Work Sans)
    • Geometric vs humanist (Poppins + Lora — geometric heading, organic body)

    Anti-patterns: pairing two display fonts (chaos), pairing two serifs from different historical eras (uncomfortable), or using the same font at the same weight for headings and body (no hierarchy). Pick one axis of contrast; keep everything else aligned.

    How to find a font pair

    1. Open the Google Fonts pair finder
    2. Pick a curated pair from the gallery, or set a heading font and a body font manually
    3. Watch the live preview — heading at H1/H2/H3 sizes, body at 16px
    4. Adjust font weights (400 / 500 / 700) to fine-tune the look
    5. Click Copy <link> + CSS for production-ready code

    The CSS you’ll paste

    <!-- in <head> -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600&family=Playfair+Display:wght@700&display=swap" rel="stylesheet">

/* in CSS */
:root {
  --font-heading: "Playfair Display", Georgia, serif;
  --font-body: "Inter", system-ui, sans-serif;
}
h1, h2, h3 { font-family: var(--font-heading); }
body { font-family: var(--font-body); }

    The preconnect hints save 100–200ms on first font load. display=swap ensures text renders in a system fallback while the web font loads, then swaps in (rather than showing invisible text during font-load).

    Performance — only load weights you actually use

    Each font weight (400, 500, 600, 700) is a separate download. Loading all eight weights of a font family adds 200+ KB; loading only 400 + 700 is typically 80 KB. Audit your design and request only the weights and styles you actually use:

    • Body: 400 (regular) and 700 (bold) is enough for most projects.
    • Headings: usually one weight — pick 700 for impact, 600 for softer headings, 800–900 for display work.
    • Italic: only request ital if your design uses italics. Many web designs don’t.
    • Variable fonts (Inter, Roboto Flex, Recursive) — load one variable font file that covers all weights, often smaller than two separate static weights.

    Common gotchas

    • Don’t pair two display fonts. One eye-catching font is contrast; two is chaos. Use one display font for headings, a neutral sans or serif for body.
    • Subset to the languages you support. Google Fonts loads only Latin by default, but for sites with Cyrillic, Greek, Vietnamese, or other scripts you must add the subset parameter — otherwise non-Latin characters fall back to a system font.
    • Self-host for GDPR compliance. Google Fonts CDN includes IP-address logging at Google. EU GDPR-strict sites self-host fonts via google-webfonts-helper or the Fontsource npm packages. Same fonts, no third-party request.
    • Variable fonts have axis ranges. Inter Variable goes from weight 100 to 900 in a single file. Specify font-weight: 525 for a custom in-between weight — useful for matching specific brand specs.
    • Body text needs ~16px minimum. Anything smaller fails accessibility recommendations (WCAG-AAA prefers 18px+) and causes mobile zoom-in. Don’t pair a “delicate” body font under 14px.
    • Cumulative Layout Shift (CLS). Web fonts swapping in shifts text reflow. Use font-display: optional to skip the swap on slow connections, or size-adjust CSS to match fallback metrics — both prevent CLS.

    When NOT to use a font pair

    Single-font designs work for many modern apps (Apple’s HIG uses just SF Pro across the system). If your interface is mostly text with little visual hierarchy, one well-designed font with clear weight differences (400 / 500 / 600 / 700) is enough. Pairing adds complexity — only do it when visual contrast helps the reader. For brand-heavy sites where the typography is the brand (publications, fashion, agencies), pairing matters more; for typical SaaS and dashboards, a single variable font is often the right answer.

    Frequently asked questions

    How many fonts should I use on a site?

    Two is the sweet spot — heading + body. One font (with weight variation) is acceptable for utilitarian designs. Three or more usually creates visual noise. Some designers add a third “accent” font sparingly for pull quotes or small UI details, but never for body text.

    Should I self-host Google Fonts?

    For privacy-strict (GDPR-leaning) sites, yes — use Fontsource npm packages or google-webfonts-helper to self-host. For everyone else, Google Fonts CDN is fine — fast, cache-friendly, free. The 2022 German court ruling against using Google Fonts CDN applies under specific GDPR interpretations and is rarely enforced internationally.

    Why does my page flash a different font on load?

    FOIT (flash of invisible text) or FOUT (flash of unstyled text) — caused by web fonts loading after the first paint. Use font-display: swap in your @font-face or Google Fonts URL, plus preconnect hints. For full elimination, preload the critical font subset with <link rel="preload">.

    Are variable fonts better than separate weight files?

    Usually yes for projects using 3+ weights — one variable file is smaller than 3+ static weights and gives you any in-between weight for free. For 1–2 weight projects, static files load slightly faster (variable files have a fixed parse overhead). Inter Variable, Roboto Flex, and Recursive are excellent variable fonts on Google Fonts.

    Is my data uploaded?

    No. The pair finder runs in your browser. Font selections, the live preview, and exported CSS stay on your device.

    Can I find a pair for a non-Latin script?

    Yes — pick a font that supports your script (toggle the language filter to Cyrillic, Greek, Arabic, Devanagari, etc.) and the tool restricts the gallery to fonts with full coverage. Body fonts for non-Latin scripts often need different pairings than Latin equivalents.

    Related tools and guides

     

  • SHA-512 Hash Generator: Compute 512-bit Digests [2026]

    SHA-512 Hash Generator: Compute 512-bit Digests [2026]

    TL;DR: SHA-512 produces a 512-bit (64-byte / 128 hex character) cryptographic hash from any input. It’s the strongest member of the SHA-2 family — 128-bit collision resistance, used for high-assurance file checksums, code-signing, password derivation (with bcrypt/argon2 wrappers), and forensic integrity verification. Our free SHA-512 hash generator uses the browser’s native SubtleCrypto API — same engine browsers use for HTTPS — and runs entirely on your device.

    SHA-512 is the largest of the SHA-2 family. It produces a 512-bit digest twice the size of SHA-256, with corresponding security against collision attacks. For most checksum use cases SHA-256 is enough; SHA-512 wins where you need extra margin (long-lived archive integrity, code-signing certificates valid for 5+ years, forensic chain-of-custody hashes) or where the platform standard mandates it (Git uses SHA-1 today but is migrating to SHA-256; some EU government systems specify SHA-512). On 64-bit hardware SHA-512 is actually faster than SHA-256 — it processes 8-byte blocks natively where SHA-256 processes 4-byte blocks.

    Our SHA-512 hash generator runs the browser’s native SubtleCrypto.digest('SHA-512', ...) implementation — the same code path that handles HTTPS certificate verification — and never uploads your input. Paste text or drop a file, and the hex digest appears instantly. This guide covers SHA-512 vs SHA-256 vs SHA-3, when each is the right pick, and the gotchas with binary-vs-text input encoding.

    SHA family at a glance

    Algorithm Output size Collision security Status
    MD5 128 bits Broken (collisions trivial) Checksums only, never security
    SHA-1 160 bits Broken (SHAttered, 2017) Legacy systems, Git (migrating)
    SHA-224 224 bits 112-bit security FIPS-compliant short hash
    SHA-256 256 bits 128-bit security De facto standard (TLS, Bitcoin, Git plan)
    SHA-384 384 bits 192-bit security SHA-512 truncated, used in PKI
    SHA-512 512 bits 256-bit security High-assurance, faster on 64-bit
    SHA-3 (Keccak) 224–512 bits Independent design, 128–256-bit Backup if SHA-2 ever weakens

    When to pick SHA-512 specifically

    SHA-256 is the default for almost every new system. SHA-512 makes sense when:

    • Long-lived archives. A digest you’ll verify in 20 years benefits from extra security margin. Government archives, legal-record systems, and long-term forensic chains of custody specify SHA-512.
    • 64-bit hardware. SHA-512 is 30–50% faster than SHA-256 on modern x86_64 CPUs because it processes 8-byte blocks natively. On 32-bit ARM (rare in 2026) the situation reverses — SHA-256 wins.
    • HMAC for sensitive material. HMAC-SHA-512 is preferred over HMAC-SHA-256 for high-value secrets like signing keys for code release.
    • Compliance mandates. Some EU government systems (BSI, ANSSI) specify SHA-512 minimum; some financial standards align with that.
    • Password-key derivation. PBKDF2 / Argon2 / bcrypt all support SHA-512 as the inner hash. Doesn’t make the password significantly stronger, but is sometimes specified by compliance frameworks.

    For everyday use — verify a download, hash a config file, generate a deterministic ID — SHA-256 is faster to compute and the 256-bit security is enough.

    How to compute SHA-512 in your browser

    1. Open the SHA-512 generator
    2. Type or paste text in the input — the digest appears live as you type
    3. Or drop a file — the digest is computed by streaming the bytes through SubtleCrypto, no upload
    4. Click Copy for the lowercase hex digest, or toggle UPPERCASE
    5. For HMAC mode, click HMAC, paste a key, and the HMAC-SHA-512 is computed

    Code: how to compute SHA-512 in JavaScript

    Browsers and Node.js 19+ both expose the WebCrypto API. The same code works everywhere:

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

// sha512("hello world") returns
// "309ecc489c12d6eb4cc40f50c902f2b4d0ed77ee511a7c7a9bcd3ca86d4cd86f
//  989dd35bc5ff499670da34255b45b0cfd830e81f605dcf7dc5542e93ae9cd76f"

    Common gotchas

    • Encoding matters before you hash. SHA-512 is a function over bytes, not characters. "café" in UTF-8 is 5 bytes; in Latin-1 it’s 4. The two produce different hashes. Always use UTF-8 for text input — the standard everywhere except some legacy Windows pipelines.
    • SHA-512 is not a password storage algorithm. Never store passwords as plain SHA-512 — even with a salt, the algorithm is too fast and vulnerable to GPU brute-force. Use bcrypt, scrypt, or argon2 for password storage; those use SHA internally as a building block but add deliberate slowness.
    • Trailing whitespace and line endings change the hash. A file ending with \n hashes differently from the same file ending without it. CRLF (\r\n) vs LF (\n) is a common cause of “the hashes don’t match” between Windows and macOS — normalise line endings before hashing.
    • UTF-8 BOM. A file saved as UTF-8 with BOM has an extra 3 bytes (EF BB BF) at the start. Same content, different hash. Strip BOMs if you compare hashes between platforms.
    • SHA-384 is SHA-512 truncated. SHA-384 uses the same algorithm internally, then truncates to 384 bits (96 hex chars). Both are valid SHA-2 hashes; pick based on output size needs.
    • Some legacy tools default to wrong hex case. Hex digests are case-insensitive when comparing, but tools default to lowercase or uppercase inconsistently. 309ecc... and 309ECC... represent the same hash.

    When NOT to use SHA-512

    For a password store, use bcrypt / scrypt / argon2 — those are designed to be deliberately slow against brute-force; SHA-512 alone is too fast. For non-cryptographic use cases (database keying, fingerprinting non-sensitive content), use a simpler hash like xxHash or FNV — they’re faster and don’t burn CPU on cryptographic strength you don’t need. For verifying that a small string hasn’t changed in a public ledger, SHA-256 is enough — half the bytes for the same practical security. For random-looking IDs in a URL, use a UUID or a random number; hashes are deterministic, which usually isn’t what you want for IDs.

    Frequently asked questions

    Is SHA-512 stronger than SHA-256?

    Yes — SHA-512 has 256-bit collision resistance vs SHA-256’s 128-bit. Both are far beyond what’s brute-forceable today. For most uses 128-bit security is more than enough; SHA-512 matters for long-lived archives and high-assurance contexts.

    Can SHA-512 be reversed?

    No. SHA-512 is a one-way function. Given a hash, there’s no method short of guessing every possible input that would recover the original. For “hash-cracking” attacks against weak inputs (short passwords, dictionary words), the attacker doesn’t reverse the hash — they hash candidate inputs until one matches. The defence is using slow algorithms (bcrypt) for passwords.

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

    SHA-512 processes 1024-bit blocks of data using 64-bit words. On a 64-bit CPU each word fits in a single register, giving SHA-512 a 30–50% throughput advantage over SHA-256 on modern x86_64. On 32-bit hardware (rare in 2026) the trade reverses.

    Should I use SHA-512 for password hashing?

    No, not directly. Use bcrypt, scrypt, or argon2id — those are deliberately slow and resistant to GPU brute-force. SHA-512 alone is millions of times too fast to use as a password store. Some compliance frameworks specify SHA-512 inside an HMAC or PBKDF2 wrapper; that’s fine, but plain SHA-512 of a password is a known anti-pattern.

    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. You can verify with DevTools’ Network tab.

    What’s the file size limit?

    Effectively your browser’s available memory. Files up to several GB hash via streaming on desktop browsers; mobile is more limited. Hashing a 1 GB file takes 5–15 seconds on a recent laptop.

    Related tools and guides

     

  • SHA-1 Hash Generator: Compute SHA1 Online [2026]

    SHA-1 Hash Generator: Compute SHA1 Online [2026]

    TL;DR: SHA-1 produces a 160-bit (40 hex character) hash from any input. Designed by NSA in 1995, it was the workhorse of digital signatures and certificates for two decades. Practical collision attacks were demonstrated in 2017 (the SHAttered attack from Google + CWI), so SHA-1 is broken for security — never use it to sign documents, store passwords, or verify integrity against a malicious actor. It’s still legitimately used as a non-security checksum (Git internal object IDs, legacy software hashes, file fingerprinting). Our free SHA-1 generator uses WebCrypto, runs in your browser, and is honest about when SHA-1 is the right pick.

    SHA-1 is the awkward middle child of the cryptographic hash family — newer than MD5, older than SHA-2, broken by modern attacks but still embedded everywhere a system was designed before 2017. Git stores every object by its SHA-1 hash; many enterprise systems still verify file integrity with SHA-1 against an immutable log; some legacy package managers and OS update systems haven’t migrated. Knowing when SHA-1 is acceptable and when it’s a security hole is more useful than blanket avoidance.

    Our SHA-1 hash generator uses the browser’s native SubtleCrypto.digest('SHA-1', ...) API and runs entirely on your device. Use it to compute Git-compatible object hashes, verify legacy checksums, or recreate hashes from a reference document. This guide covers exactly how SHA-1 broke, where it’s still safe, and the migration path everywhere else.

    When SHA-1 is acceptable — and when it isn’t

    Use case SHA-1 OK? Why
    Git object IDs Yes (transitioning) Git uses SHA-1 with collision-detection patches; SHA-256 mode in Git 2.29+
    Non-adversarial file checksum Yes If no attacker controls the input, accidental collisions are astronomically unlikely
    Database fingerprint key Yes Internal use, no untrusted input
    TLS certificate signature No Browsers reject SHA-1 certificates since 2017
    Code signing No Microsoft, Apple, Mozilla all rejected SHA-1 by 2018
    Password storage (any form) No Use bcrypt / argon2; never use bare SHA-1 even with salt
    HMAC for authenticated messages Maybe HMAC-SHA-1 is weakly protected; use HMAC-SHA-256 instead
    Document signing for legal use No Forgeable by a determined attacker; use SHA-256+

    What “broken” actually means — the SHAttered attack

    In February 2017 Google and CWI published SHAttered: two distinct PDF files with the same SHA-1 hash. The attack required ~6,500 CPU-years and 110 GPU-years of compute, costing roughly $110,000 in 2017 cloud compute. Today the same attack costs a fraction of that. The attack proves that SHA-1 collisions are practically findable — meaning an attacker can craft two documents (an innocent contract and a malicious one) that hash to the same value, then swap them after one is signed.

    SHA-1 is still preimage-resistant for now — given a hash, there’s no faster way than brute force to find an input that produces it. So legacy systems that store SHA-1 hashes of inputs that already exist (e.g., file fingerprints in a backup index) aren’t immediately broken. But any system that signs, certifies, or trusts a SHA-1 hash from a third party is at risk.

    How to compute SHA-1 in your browser

    1. Open the SHA-1 hash generator
    2. Type or paste text — the digest appears live
    3. Or drop a file — bytes are streamed through the browser’s WebCrypto API, no upload
    4. Click Copy. Toggle UPPERCASE or lowercase hex output
    5. For HMAC-SHA-1 (legacy auth headers), click HMAC mode and paste a key

    Code: SHA-1 in JavaScript

    Same WebCrypto API as SHA-256 / SHA-512 — only the algorithm name changes:

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

// sha1("hello world") returns
// "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed"

    Common gotchas

    • UTF-8 encoding before hashing. Same input, different encoding, different hash. "café" as UTF-8 is 5 bytes; as Latin-1 it’s 4. Modern systems use UTF-8 universally.
    • Don’t HMAC-SHA-1 anything sensitive. HMAC-SHA-1 is weakly protected against today’s attacks. Webhook signatures from old AWS APIs and some payment processors still use it; new code should use HMAC-SHA-256.
    • Git’s SHA-1 hashes are slightly different. Git prefixes each blob with "blob <size>\0" before hashing. So Git’s hash of file content isn’t the same as sha1(content). Use git hash-object or our Git mode for an exact match.
    • Collisions are findable, but unlikely by accident. An accidental SHA-1 collision in a Git repo would require ~10^48 random commits — not a real concern. The risk is malicious collision, where an attacker crafts the input.
    • SHA-1 in TLS certificates is rejected. Browsers reject SHA-1-signed TLS certificates since early 2017. If you see a certificate-warning page mentioning SHA-1, the site needs to renew its certificate with SHA-256 minimum.
    • Length-extension attacks affect bare SHA-1. Like SHA-256 and MD5, SHA-1 is vulnerable to length extension if used as sha1(secret || data). Use HMAC instead — it’s specifically designed to resist this.

    When NOT to use SHA-1

    For new code: don’t reach for SHA-1 unless an external system specifically requires it. Use SHA-256 or SHA-512 by default — both are faster than SHA-1 on 64-bit hardware (yes, actually faster — modern CPU pipelines optimise for SHA-2). For password storage: never SHA-1, always bcrypt / scrypt / argon2id. For signing or verifying digital signatures: never SHA-1; standards bodies have deprecated it for over a decade. For TLS / X.509 certificates: SHA-1 is forbidden by browsers and CAs. Use this generator only for compatibility with legacy systems that still expect SHA-1 outputs.

    Frequently asked questions

    Why is SHA-1 still used in Git?

    Git was designed in 2005 around SHA-1 — every commit, tree, and blob is keyed by SHA-1. After SHAttered, Git added collision-detection (the sha1dc library) that catches the known collision attack and rejects matching inputs. Git 2.29 (2020) added experimental SHA-256 mode; full migration is multi-year and ongoing. For everyday use, Git’s SHA-1 keys are safe enough.

    How long does it take to compute a SHA-1 collision?

    The original SHAttered attack required $110,000 of cloud compute over two months. Modern GPU farms can produce a chosen-prefix collision in under a day for a few thousand dollars. Both are still expensive enough that most attackers won’t bother — but cheap enough that any system signing third-party documents with SHA-1 should migrate.

    Is SHA-1 still preimage-resistant?

    Yes, for now. Preimage resistance — given a hash, find an input that produces it — is much harder than collision resistance. No public preimage attack on SHA-1 exists. Systems that verify a hash of an existing file aren’t immediately broken; systems that trust a hash from an untrusted source are.

    Can I migrate my SHA-1 system to SHA-256?

    Yes — SHA-256 is a drop-in replacement for new hashes (output is twice as long: 64 hex chars vs 40). Migration plan: stop generating new SHA-1 hashes; recompute existing critical hashes in parallel as SHA-256; verify both during a transition period; remove SHA-1 once all consumers handle SHA-256.

    Is my input uploaded?

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

    Why are SHA-2 hashes faster than SHA-1 in 2026?

    Modern CPUs include hardware acceleration for SHA-2 (Intel SHA-NI, ARMv8 SHA extensions). SHA-1 doesn’t get the same hardware path on most chips. On a 2024 laptop, SHA-256 is typically 1.5–2× faster than SHA-1 for large inputs.

    Related tools and guides

     

  • Image Filters Online: Free Browser Photo Effects [2026]

    Image Filters Online: Free Browser Photo Effects [2026]

    TL;DR: An online image-filter tool applies CSS-style adjustments — brightness, contrast, saturate, hue-rotate, blur, sepia, grayscale — and prebuilt presets (vintage, cool, warm, fade) to any photo, in your browser. Useful for quick blog hero images, social posts, and matching photos to a brand palette without opening Photoshop. Our free image filter tool runs the entire pipeline on the canvas in your browser, exports the filtered image as PNG/JPG/WebP, and copies the equivalent CSS filter declaration so you can apply the same effect live in your stylesheet.

    Reaching for Photoshop or Lightroom for a quick photo tweak is overkill when all you need is a brightness boost, a sepia tint, or a quick fade for a blog header. Mobile apps like Snapseed and VSCO solve this on phones; the equivalent for desktop work is a browser tool with the same set of named effects. CSS specifies all the basic image filters — brightness(), contrast(), saturate(), blur(), sepia(), grayscale(), hue-rotate(), invert(), opacity(), drop-shadow() — and most browsers render them at GPU speed.

    Our image filter tool exposes every CSS filter as a slider plus 24 prebuilt presets (vintage, cool, warm, fade, sepia, B&W, dramatic, polaroid, and more). Drop an image, drag sliders or click a preset, export the filtered image as PNG/JPG/WebP. The tool also outputs the equivalent CSS filter: declaration — useful when you want to apply the filter in CSS (live, no rendered file) instead of baking it into the image. This guide explains every filter, the preset presets, and the gotchas with hue-rotate and saturate that produce unexpected results.

    All 10 CSS filter functions

    Filter Range What it does
    brightness(0–2) 0% to 200%+ Linearly scales the intensity of every pixel
    contrast(0–2) 0% to 200%+ Spreads pixel values away from mid-grey
    saturate(0–2) 0% to 200%+ 0% = grayscale; 200% = oversaturated
    grayscale(0–1) 0% to 100% Mixes original and luminance-only versions
    sepia(0–1) 0% to 100% Brown-tinted aging effect
    hue-rotate(0–360deg) 0° to 360° Spins all colours around the colour wheel
    invert(0–1) 0% to 100% Inverts pixel values (negative effect)
    blur(0–20px) 0px to 20px+ Gaussian blur — soften details
    opacity(0–1) 0% to 100% Fade entire image to transparent
    drop-shadow() x / y / blur / colour Shadow that follows non-rectangular silhouettes

    24 prebuilt presets — what each one does

    Filters compose. Stacking contrast(110%) saturate(140%) sepia(20%) produces the “Polaroid” look. Our presets are tuned versions of those compositions:

    • Vintage: warm sepia with reduced saturation and slight contrast boost — instagram circa 2012
    • Cool: blue hue shift and increased contrast — winter photography
    • Warm: orange/yellow tint and slight saturation — sunset feel
    • B&W: grayscale with contrast boost — photojournalism look
    • Fade: reduced saturation and contrast — film fade
    • Sepia: classic 100% sepia tint
    • Polaroid: warm tint, soft contrast, slight grain
    • Dramatic: high contrast + saturation
    • Forest: green-shifted hue + saturation
    • Sunset: orange-shifted hue + warm tint
    • Night: deep blue + reduced brightness
    • Lo-fi: pixel-soft blur + saturation
    • … 12 more available in the dropdown

    How to filter an image in your browser

    1. Open the image filter tool
    2. Drop an image (JPG, PNG, WebP, HEIC supported)
    3. Click a preset to apply, or drag individual filter sliders
    4. Watch the live preview update — every change is canvas-rendered in real time
    5. Click Export for PNG/JPG/WebP at 1× / 2× / 4× resolution
    6. Or click Copy CSS to copy the equivalent filter: declaration for live styling

    CSS filter vs baked-in filter — when to pick which

    Two output options matter for different workflows:

    • Bake into image: the filter is applied to the pixels, the image is exported as PNG/JPG. Use when you’re publishing to a CMS, social media, or anywhere the image lives independently of styling. The filter is permanent.
    • Copy as CSS: the original image stays untouched and you apply the filter via img { filter: contrast(120%) saturate(110%); } in your stylesheet. Use when you want one source image to render different ways across themes (light/dark mode, hover states, etc.). The filter is reversible — change the CSS and the image looks different without re-uploading.

    For a photo gallery with hover effects, use CSS. For an image you’ll embed in a tweet or attach to an email, bake it in.

    Common gotchas

    • Hue-rotate isn’t perceptually uniform. Rotating hue by 60° shifts red to yellow, but the same 60° shift from blue lands in purple — the wheel isn’t uniform. Use the visual preview, don’t pick angles by intuition.
    • Brightness above 100% can clip highlights. Once a pixel hits #FFFFFF it stops getting brighter, and details in the highlights are lost forever. Pull contrast down before pushing brightness up if you want to preserve detail.
    • Blur slows older devices. Gaussian blur with radius >10px on a 4000×3000 image can briefly stall the page on a 5-year-old mobile. Resize the image first if performance matters.
    • Grayscale isn’t desaturate. grayscale(100%) uses Rec. 709 luminance weights (red 21%, green 72%, blue 7%); saturate(0) uses an HSL-style desaturation. The two produce subtly different greys for the same input.
    • Drop-shadow follows transparency. Unlike box-shadow, drop-shadow() respects PNG alpha channels — perfect for product photos with transparent backgrounds. JPEG inputs don’t have alpha, so the shadow shows the rectangular outline.
    • Sepia at 100% destroys colour information. Once an image is fully sepia-toned, you can’t recover the original colours from the output. Always keep your original — bake the filter into a copy.

    When NOT to use this tool

    For photography retouching (skin smoothing, dodge/burn, layered adjustments), use Lightroom, Photoshop, or Affinity Photo — CSS filters can’t do localised edits. For colour grading a video sequence, use a video editor with proper LUT support (DaVinci Resolve, Premiere). For batch processing 100s of files, install sharp or ImageMagick and write a script — much faster than running each through a browser tool. For HDR or 16-bit colour work, browsers run filters in 8-bit RGB and can lose precision.

    Frequently asked questions

    Does this support PNG alpha channels?

    Yes. PNG transparency is preserved through every filter. Drop-shadow specifically follows the alpha channel — useful for product photos on transparent backgrounds. JPEG inputs don’t have alpha; everything outside the photo is treated as fully opaque.

    Can I export to WebP?

    Yes — the export menu offers PNG (lossless, alpha), JPG (lossy, no alpha), and WebP (modern compression, alpha supported). Pick PNG for graphics with transparency, JPG for photos, WebP for the smallest file when modern browser support is acceptable.

    Will the filtered output match what I see in CSS?

    Yes — we use the same canvas filter API browsers use for the CSS filter property, so the rendered output is byte-identical to what your stylesheet would produce on a browser of the same version. Older browsers may render slight differences in blur kernels.

    Can I apply multiple filters at once?

    Yes — every slider is independent and they all stack. The preview shows the cumulative effect; the exported CSS lists each filter in order (filter: brightness(110%) contrast(120%) sepia(20%)). The order matters slightly — earlier filters are applied first.

    Is my image uploaded?

    No. The tool runs canvas filters in your browser. The image is loaded into a blob URL and processed locally — never uploaded.

    What’s the resolution limit?

    Effectively your browser’s available canvas memory. Desktop browsers handle 8000×6000 (48 MP) images comfortably; mobile is more limited (around 4000×3000). Heavy filters like blur slow down on large inputs — resize first if you don’t need full resolution.

    Related tools and guides

     

  • Bionic Reading Converter: Speed-Read Any Text [2026]

    Bionic Reading Converter: Speed-Read Any Text [2026]

    TL;DR: Bionic reading is a typographic technique that bolds the first 1–4 letters of every word (“fixation points”) with the rest in normal weight. The premise: bold lead-letters give the eye anchor points so it can skim faster while inferring the rest of each word. Reader response is mixed — some people read 20–30% faster, others find it visually noisy. Our free bionic reading converter applies the formatting to any text with adjustable fixation ratio, then exports HTML, PDF, or copies rich-text to clipboard. Browser-only.

    Bionic Reading was popularised by a 2022 viral demo from a Swiss company. The idea: human reading speed is bottlenecked by the eye’s saccadic jumps between words, and bolding the leading letters gives the eye a clearer landing target — increasing reading speed without sacrificing comprehension. Some readers describe it as a noticeable boost, especially for skimming long technical articles; others call it visually distracting and slower. Like all reading aids, mileage varies.

    Our bionic reading converter applies the formatting to any text you paste, with a slider for fixation ratio (how many letters to bold). Output is rich HTML you can copy-paste into a Doc or Notion, or export as PDF/HTML for printing. The conversion runs entirely in your browser — your text never leaves your device. This guide explains how the algorithm works, the research-vs-marketing claims, and when bionic formatting is genuinely useful (and when it gets in the way).

    How the formatting works (the algorithm)

    Word length Letters bolded (default) Example
    1–3 letters 1 an, the, it
    4 letters 2 that, from
    5–6 letters 2 or 3 strong, beyond
    7–10 letters 3 or 4 fixation, reading
    11+ letters 4 or 5 technology, cognition

    The fixation ratio slider lets you adjust this aggressiveness. Lower (e.g., bolding only ~30% of each word) is subtler; higher (~60%+) is heavier and may feel cluttered. The original Bionic Reading uses ~50% by default.

    Does it actually help reading speed?

    The marketing claim is “up to 200% faster”. The peer-reviewed research is more modest. A 2022 study by the University of Cambridge found no statistically significant reading-speed improvement across 200 subjects. Independent psycholinguists have pushed back on the broader claims. So the honest answer: bionic reading doesn’t make most people faster.

    What it does seem to help with, anecdotally:

    • ADHD readers: some users with ADHD report that bionic format helps them maintain focus on long passages — bold lead-letters work as visual anchors that re-engage attention.
    • Skimming. When the goal isn’t full comprehension but skimming for keywords, bionic format helps pull the gaze across faster.
    • Cognitive load on dense material. For some readers, the visual structure makes paragraph-shaped walls of text less daunting.
    • Dyslexic readers. Reports are mixed — some dyslexic readers find it helpful, others find the visual noise harder to parse.

    If you’re considering bionic formatting as an accessibility feature, test with the actual readers it’s meant to help — don’t assume it works for everyone.

    How to convert text to bionic reading

    1. Open the bionic reading converter
    2. Paste your text in the input
    3. Adjust the fixation slider (default 50% — half the letters of each word bolded)
    4. Pick output format: HTML (paste into Doc or Notion), Rich text (clipboard), or PDF
    5. Click Copy or Download

    The HTML output (and why rich-text matters)

    Plain text can’t carry the bold formatting; you need rich HTML. The converter outputs HTML like this:

    <p>
  <strong>Bo</strong>ld 
  <strong>th</strong>e 
  <strong>fir</strong>st 
  <strong>hal</strong>f 
  <strong>of</strong> 
  <strong>ev</strong>ery 
  <strong>wor</strong>d.
</p>

    Pasting this into Notion, Google Docs, or any rich-text editor preserves the bold formatting. Pasting into a plain-text editor strips the HTML and you get the original text without bolding. Use the “Copy as Rich Text” button in our tool — it puts both HTML and plain-text versions on the clipboard, and the destination app picks whichever it supports.

    Common gotchas

    • Hyphenated words become odd. “Self-aware” with bionic formatting becomes “Self-aware”, which most readers find harder, not easier. Our converter has an option to skip words shorter than 4 characters and to treat hyphenated words as a unit.
    • Numbers and code snippets shouldn’t be bionic-formatted. “404 not found” with bolding becomes confusing. The converter detects numeric words and code-fenced text (markdown `code`) and skips them by default.
    • Doesn’t work in pure plain text. Email-only readers, plain-text terminals, and any non-rich-text destination strip the formatting. Use HTML or PDF for digital sharing.
    • Don’t mass-convert your reading list. The format works for some content (dense technical articles) and against others (poetry, fiction, copy-edited prose where typography matters). Convert per-document, not by default.
    • Accessibility considerations. Bold text increases visual noise for some users with low vision or specific reading disabilities. Always offer a toggle to view the original — never force bionic formatting on readers without consent.
    • Trademark issue. “Bionic Reading” is a trademarked name owned by Bionic Reading AG. Open-source equivalents go by names like “OpenDyslexic Reading” or just “fixation reading” to avoid the trademark — our tool uses the term “bionic reading” as the descriptive technique name, not as the brand.

    When NOT to use bionic reading

    For literary or carefully-written prose where the rhythm of the language matters, bionic formatting interferes with the reading experience the author intended. For poetry — never use it; the visual structure of the poem is part of the meaning. For language learners reading in a foreign language, bionic formatting can confuse word-segmentation as you’re still building your mental dictionary. For ebook readers (Kindle, Kobo), most don’t preserve rich-text bolding consistently — convert just before reading, not as a permanent storage format. For accessibility certifications (WCAG), bold-heavy content can fail readability thresholds.

    Frequently asked questions

    Does bionic reading actually make me read faster?

    Studies are mixed. A 2022 Cambridge study found no significant speed improvement across the general population. Anecdotally, some readers — especially those with ADHD — report subjective benefit. Try it on your own typical reading material and decide.

    Can I use this for ebooks?

    Yes — convert a chapter to PDF or HTML, then transfer to your ebook reader. Most readers preserve bold formatting in EPUB and PDF. Kindle’s older firmware sometimes drops bold; test on your specific device.

    Is this the same as the trademarked “Bionic Reading”?

    It’s the same technique. “Bionic Reading” is a trademark of Bionic Reading AG; we use the term descriptively (like “spell check” or “track changes”). The algorithm is straightforward and unpatented; many open-source implementations exist.

    Can I customise how aggressive the bolding is?

    Yes — the fixation ratio slider goes from very subtle (~30% of each word bolded) to heavy (~70%). Default is 50%, matching the original tool. Lower ratios are easier on the eyes; higher ratios produce stronger anchor points for skimming.

    Is my text uploaded?

    No. The converter runs in your browser. Pasted text never leaves your device — useful when converting drafts, internal documents, or anything you’d rather not share with a third party.

    Does it work with non-English text?

    Yes — the algorithm is language-agnostic; it bolds the first portion of each space-separated word. It works with any language that uses spaces between words (most European languages, Vietnamese, etc.). Languages without word spaces (Chinese, Japanese, Thai, Korean) need a tokeniser before formatting; our tool detects and warns when input lacks word boundaries.

    Related tools and guides

     

  • Test IBAN Generator: Valid Format Mod-97 [2026]

    Test IBAN Generator: Valid Format Mod-97 [2026]

    TL;DR: A test (or “fake”) IBAN generator produces strings that look like real International Bank Account Numbers — correct length per country, correct mod-97 check digit — but are not real accounts. Use them for QA-testing payment forms, generating synthetic test data, classroom examples, and validating IBAN-parsing logic. Our free test IBAN generator covers 75+ countries with the correct format per each, runs in your browser, and is honest about the only legitimate use case: testing.

    Every payment system that accepts an IBAN runs at least two checks: format (length and structure must match the country’s IBAN spec) and mod-97 (the two check digits must produce a remainder of 1 when the IBAN is interpreted as a giant integer modulo 97). A randomly-typed string fails one or both. Building or testing payment software requires inputs that pass these checks but aren’t connected to a real account — that’s where test IBANs come in.

    Our test IBAN generator produces format-correct, mod-97-valid IBANs for 75+ countries. The bank code, branch code, and account number sections are randomly filled — but with the right number of digits per country (Germany: 22 chars total, UK: 22, France: 27, Italy: 27, etc.). The resulting IBAN passes IBAN-format validators (which only check structure), but no bank in the world has that account. This guide covers when test IBANs are appropriate, the legal lines you must not cross, and the gotchas that have surprised people who thought “test IBANs” meant “free money”.

    Legitimate uses for test IBANs

    Use case OK? Why
    QA testing a payment form Yes Validates format / mod-97 logic without using real data
    Synthetic data for unit tests Yes Test fixtures need consistent, valid-shape data
    Classroom / training examples Yes Demonstrate format without using real accounts
    Mockup screenshots and slides Yes Realistic-looking placeholder data
    Filling out a real bank form No Will be flagged as suspicious; can be fraud depending on intent
    Setting up a recurring direct debit No Will fail at the bank’s account-existence check
    “Free trial” abuse No Most fraud / consumer-protection law applies; credit-card-fraud-equivalent in many jurisdictions

    The only safe rule: test IBANs are for testing your code or learning the format. They’re not a workaround for any real-world process that demands a real bank account.

    How an IBAN is structured

    An IBAN is a fixed-format string defined by ISO 13616. The structure varies per country but always follows this pattern:

    • 2 letters: ISO country code (DE, FR, GB, IT, US — but US doesn’t issue IBANs natively)
    • 2 digits: Mod-97 check digits
    • Variable digits/letters: Bank code, branch code, account number — country-specific structure

    Total length: 15 to 34 characters depending on country. Germany is 22, UK is 22, France is 27, Italy is 27, Saudi Arabia is 24. The full per-country structure is published by SWIFT and ECBS.

    The mod-97 check (and why it works)

    The check is an integrity protection against typos: take the IBAN, move the first 4 characters to the end, replace each letter with a 2-digit number (A=10, B=11, …, Z=35), then compute the resulting giant integer modulo 97. The result must be 1.

    This catches single-digit typos with high probability and most transposition errors. It doesn’t verify that the account exists — only that the format is internally consistent. So a generated IBAN passes mod-97 (we compute the check digits correctly) but a bank’s account-lookup will return “no such account”.

    How to generate test IBANs

    1. Open the test IBAN generator
    2. Pick a country (Germany default — 75+ supported)
    3. Click Generate. The IBAN appears with proper formatting (groups of 4 digits separated by spaces)
    4. Click Copy — the IBAN is copied without spaces (IBANs are stored without spaces; spaces are display-only)
    5. Generate batches of 10/100/1000 with the Bulk button for stress-testing payment forms

    Common gotchas

    • Format-valid is not account-valid. Our IBANs pass mod-97 and length checks. Banks’ real account-lookup APIs (e.g., SEPA RT1 / SCT) will reject them with “account not found” because no matching account exists. Use real test accounts from your payment provider for end-to-end testing.
    • Country-specific bank codes. Some countries (Germany, France, Italy) have published lists of valid bank codes. Our generator uses random bank codes that may or may not match a real bank — but the IBAN format remains valid. Some validators check both format AND that the bank code is in the official list.
    • SWIFT/BIC generation is separate. An IBAN by itself isn’t enough for international transfers — you also need a BIC (also called SWIFT code). Our tool generates IBAN only; for test BICs, see the SWIFT registry’s list of “00000” test prefixes.
    • Spaces don’t matter for storage. IBANs are stored as compact strings: DE89370400440532013000. Display format groups them: DE89 3704 0044 0532 0130 00. Both are equivalent.
    • Lowercase is wrong. Real IBANs use uppercase letters only. de89... is not a valid IBAN. Our generator outputs uppercase; if you typed an IBAN with lowercase, normalise before validation.
    • SEPA-extended countries. Some non-EU countries (UK post-Brexit, Switzerland, Norway) participate in SEPA and use IBAN format. Some countries (US, Canada, Australia, India, China) don’t issue IBANs at all — they use their own account number formats.

    When NOT to use a test IBAN

    For end-to-end payment testing (where money actually moves), use the test environment provided by your payment processor — Stripe, Adyen, GoCardless, Mollie all have test IBAN suites with predictable behaviour (test IBAN A succeeds, test IBAN B fails with “insufficient funds”, test IBAN C times out, etc.). For real-world use, never. For training data in machine learning models, use clearly-labeled synthetic data and document its provenance — confusing test IBANs for real ones in a model’s training set is a privacy and accuracy issue.

    Frequently asked questions

    Are these IBANs real?

    No. They’re format-valid (correct length, valid mod-97 check digits) but not connected to any real bank account. Any real bank’s account-lookup API will return “account not found”.

    Can I use these in production?

    Only as test data: in unit tests, integration tests, mock-up screenshots, classroom examples, or stress-testing your payment form. Submitting them to a real bank or merchant where you’d be expected to provide a real account is misleading and may be illegal depending on jurisdiction.

    Will my payment processor accept these for testing?

    For format-validation testing, yes — they pass the format/mod-97 check that most processors run before submitting to the bank. For end-to-end testing, no — you need test IBANs from your processor’s documented test suite that produce predictable success/failure responses.

    Why are some country IBANs longer than others?

    Country-specific banking systems use different account-number formats. France includes a 5-digit branch code; Germany uses a different 8-digit bank code; Italy includes a 1-character “CIN” check character. Total IBAN length ranges from 15 (Norway) to 34 (Saint Lucia). Each country’s structure is published by SWIFT.

    Is my data uploaded?

    No. The generator runs in your browser. Generated IBANs are computed locally — never sent to our servers.

    Can I validate an existing IBAN with this tool?

    Yes — paste an IBAN into the validator mode and the tool checks format and mod-97. It does NOT check whether the IBAN points to a real account; that requires a bank API. For format validation in production, use a library like ibantools (Node) or iban (Python).

    Related tools and guides

     

  • Extract Colors from Image: Auto Palette Tool [2026]

    Extract Colors from Image: Auto Palette Tool [2026]

    TL;DR: An image color extractor analyses a photo or graphic and returns the 2–12 most representative colours as a palette. Behind the scenes most extractors run K-means clustering on the pixel data, sort the resulting clusters by population, and output each centroid as HEX/RGB/HSL. Use it for moodboards, brand palettes from a photo, theme generation, or matching ad creative to a hero image. Our free image color extractor runs entirely in your browser, supports up to 12 colours, and exports CSS variables ready to drop into your stylesheet.

    Designers extract colour palettes from images constantly. A photographer wants the dominant tones of a portrait for the gradient behind a website hero. A brand strategist needs the four real colours from a screenshot of a competitor’s ad. A film designer wants the palette of a single frame to match the rest of the spread. Doing this by eye works for two or three colours; doing it accurately for ten requires an algorithm that looks at every pixel.

    Our image color extractor runs K-means clustering directly in your browser via WebAssembly. Drop an image, pick how many colours (2 to 12), and the tool returns the centroids ranked by how much of the image each colour represents. Each swatch shows HEX, RGB, HSL, OKLCH, and the WCAG contrast ratio against black and white — useful for picking accessible text colours from a brand photo. This guide covers how K-means works in colour space, why it sometimes returns near-duplicate colours, and the gotchas with transparent backgrounds and EXIF rotation.

    When to use a palette extractor

    Use case Recommended count What you do with it
    Hero gradient from a photo 2–3 colours Use top 2 as gradient stops
    Brand palette from a logo 3–5 Verify exact brand HEX values
    Moodboard / inspiration 5–8 Save the swatches as a Figma library
    Album cover analysis 5–6 Generate a matching theme
    Ad creative colour match 3–4 Paint background to harmonise with image
    Competitor screenshot study 8–10 Audit their full palette

    How K-means clustering works (in colour terms)

    Plot every pixel as a point in a 3D colour space (RGB, or better still OKLab for perceptual uniformity). K-means then partitions those points into k clusters by:

    1. Pick k initial cluster centres at random (or via k-means++ for better starting points)
    2. Assign every pixel to the nearest centre
    3. Recompute each centre as the average of the pixels assigned to it
    4. Repeat steps 2–3 until centres stop moving (convergence)

    The output is k colours that minimise the total distance between every pixel and its assigned centre. Cluster size (number of pixels assigned) tells you how dominant each colour is in the original image.

    We use OKLab as the clustering space — distances in OKLab roughly match human perception, so two colours that look similar are also close in OKLab. Older extractors run K-means in raw RGB and produce odd results when an image has a wide hue range (RGB distance treats yellow and blue as much closer than the eye does).

    How to extract a palette in your browser

    1. Open the image color extractor
    2. Drop an image (JPG, PNG, WebP, HEIC supported)
    3. Pick the colour count (2–12)
    4. The palette appears in 1–3 seconds with each swatch labelled by HEX and percentage of the image
    5. Toggle Sort by percentage or Sort by hue
    6. Click any swatch to copy its HEX, RGB, HSL, or OKLCH
    7. Click Export CSS variables to download a --brand-N variable block ready to paste into :root

    Common gotchas

    • Near-duplicate colours. If your image is mostly skin tones, K-means with k=10 returns ten variations of the same beige. Drop k to 4–5, or use the “merge similar” option which post-processes the output to deduplicate within a perceptual distance threshold.
    • Transparent backgrounds skew the result. A logo on transparent background still has many fully-transparent pixels — by default we skip those. If your output looks wrong, check that the “ignore transparent” toggle is on.
    • EXIF rotation isn’t honoured by all extractors. A portrait photo from a phone is often stored as a landscape file with EXIF rotation metadata. Our tool reads the EXIF rotation and re-orients before extraction. Some tools don’t, and produce confusing palettes from the wrong “side” of the image.
    • JPEG compression artefacts inflate the palette. Compressed JPGs introduce subtle colour fringes near edges. K-means treats these as legitimate colours and may include them. Using a slightly higher k and merging similar colours afterward gives cleaner output.
    • Resolution matters less than you think. The tool downsamples to ~512×512 internally before clustering. A 4000×3000 photo and an 800×600 version of the same image produce nearly identical palettes — clustering is statistical, not pixel-perfect.
    • Random initialisation = slightly different output each run. K-means uses random starting points, so two runs on the same image can return slightly different palettes (within ~5% colour distance). For reproducibility, use the seeded mode with a fixed seed.

    Accessibility — pick text colours from the palette

    A common workflow: extract a palette from a hero photo, then use one of the extracted colours as the background and need a text colour that meets WCAG contrast on it. Each swatch in our output shows the contrast ratio against black and white — pick the colour combination with a ratio above 4.5:1 (AA standard for body text) or 7:1 (AAA). For coloured-text-on-coloured-background combinations, our “Pair check” overlay shows the contrast between any two extracted colours.

    When NOT to use this tool

    For brand-exact colours from a logo SVG, open the SVG and read the fill values directly — extraction approximates and can introduce small errors. For animated GIFs, the extractor uses only the first frame; for the full palette across all frames you’ll need a video-aware tool. For very small icons (under 64×64), there often aren’t enough pixels for K-means to produce a meaningful palette — pick the colours by eye instead. For batch processing many images in a CI pipeline, install node-vibrant or color-thief locally and write a script — much faster than running this tool by hand on each file.

    Frequently asked questions

    How accurate is the extracted palette?

    K-means in OKLab space gives results that closely match what a designer would pick by eye. The dominant 1–2 colours are virtually exact; minor colours can vary by a few HSL points between runs because of random initialisation. For pixel-perfect brand colours, sample directly from the source file with an image color picker instead.

    How many colours should I extract?

    3–5 for design palettes, 2 for hero gradients, 8+ for moodboards and competitive analysis. More than 8 colours often produces near-duplicates; fewer than 3 misses meaningful tones. Start with 5 and adjust.

    Why does the same image return different palettes?

    K-means uses random initialisation, so two runs can produce slightly different centroids. Differences are usually under 5% perceptual distance. Use the seeded mode (with a fixed seed string) for reproducible output across runs.

    Does it support transparent backgrounds?

    Yes — fully-transparent pixels are skipped by default. Semi-transparent pixels are blended against your chosen “background colour” (white by default). Toggle the background to dark or your brand colour for accurate extraction from logos with see-through regions.

    Is my image uploaded?

    No. The extractor runs K-means in your browser via WebAssembly. The image is loaded into a blob URL and the pixel data is processed locally — never uploaded.

    Can I export the palette in a specific format?

    Yes — the export menu offers JSON (programmatic), CSS variables (--brand-1: #... ready for :root), Tailwind config (drop into theme.extend.colors), Adobe ASE swatch file, and a PNG of the palette swatches.

    Related tools and guides

     

  • Image to Base64 Converter: Data URL Encoder [2026]

    Image to Base64 Converter: Data URL Encoder [2026]

    TL;DR: An image-to-Base64 converter encodes any image (PNG, JPG, WebP, SVG, GIF) as a Base64 string and wraps it in a data:image/;base64,... URL, ready to paste into HTML src, CSS url(), or JSON. Use it for inline icons under 4 KB, email templates that demand inline assets, and small SVGs that don’t justify a network request. Our free image-to-Base64 converter runs entirely in your browser — drag and drop any image, copy the result.

    A Base64 data URL inlines an image directly into HTML, CSS, or JSON. Instead of <img src="logo.png"> with a network request, you write <img src="data:image/png;base64,iVBORw0KGgo..."> and the image is part of the document. That eliminates the round-trip — useful for tiny icons in critical CSS, email templates that demand inline assets (Gmail blocks externally-hosted images by default), and JSON payloads where a separate file isn’t an option (push notifications, web push payloads, embedded widget configs).

    Our image to Base64 converter handles every common format, runs in your browser (the file never uploads), and gives you four output shapes — raw Base64, full data URL, CSS url(), and HTML <img> tag. This guide covers when inlining is the right call (often it isn’t), the size overhead (~33%), and the gotchas with caching, gzip, and font-icon migration.

    When to inline an image as Base64 — and when not to

    Use case Inline as Base64? Why
    Icon under 4 KB in critical CSS Yes Saves a request on the critical path
    HTML email template Yes (often required) Most clients block external images by default
    Large hero image (> 50 KB) No Inflates HTML, blocks parsing, no CDN caching
    Image used on every page No External file caches once, serves N times
    SVG icon set used 5+ times per page Maybe — try SVG sprite first Sprite sheets compress better than per-icon Base64
    Embed widget configuration JSON Yes JSON can’t reference external files
    Push notification icon Yes Browser push payloads are limited and need self-contained data

    The 33% size penalty

    Base64 encodes 3 raw bytes as 4 ASCII characters. That’s a 33% size overhead before any other effects. A 12 KB PNG becomes a ~16 KB Base64 string. For text-mode HTTP responses (HTML, CSS, JSON), gzip compresses the Base64 string back down — typically to within 5–8% of the original binary size. So the true overhead in a gzipped HTTP response is small.

    What gzip can’t fix: Base64-inlined assets are part of the HTML, so they block the HTML parser longer. They can’t be cached separately by the browser — every page load redownloads the whole HTML including the inline image. For an icon shown on every page, this trades a one-time round-trip for a recurring kilobyte penalty. Run the math.

    How to convert an image to Base64

    1. Open the image to Base64 converter
    2. Drop your image, click to pick a file, or paste from clipboard
    3. The converter detects the MIME type automatically (image/png, image/jpeg, image/svg+xml, etc.)
    4. Pick output format: Raw Base64, Data URL, CSS url(), or HTML <img> tag
    5. Click Copy — paste into your HTML, CSS, or JSON

    Output shapes — paste-ready for every context

    The same image produces four different output strings depending on where you’ll paste it:

    // Raw Base64
iVBORw0KGgoAAAANSUhEUgAA...

// Data URL — works in HTML src, CSS url(), JS Image()
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...

// CSS url()
.icon { background: url("data:image/png;base64,iVBORw...") no-repeat; }

// HTML img tag
<img src="data:image/png;base64,iVBORw0KGgo..." alt="...">

    Common gotchas

    • SVGs can be inlined more efficiently as URL-encoded SVG. Instead of data:image/svg+xml;base64,... use data:image/svg+xml;utf8,... with URL-encoded SVG markup. The result is smaller (no Base64 overhead) and gzip-compresses better. Most modern browsers support both forms.
    • Don’t inline JPEGs above ~10 KB. The Base64 string bloats your HTML by 33%, blocks the parser, and the savings from one fewer request are negligible compared to the parsing cost. Use a CDN.
    • Gmail strips inline Base64 PNGs above 4 KB in some cases. Email-client behaviour varies wildly; test with Litmus or Email on Acid before mass-mailing a campaign that depends on inline images.
    • CSP headers may block data URLs. A Content Security Policy with img-src: 'self' blocks data: URLs. Add data: to img-src if you use inline images: img-src 'self' data:;.
    • Don’t inline animated GIFs as Base64. Encoded GIF blobs are huge (often 100 KB+ for a 5-second clip), and most email clients render the first frame only anyway. Use a hosted MP4 or animated WebP for non-email contexts.
    • Build pipelines do this automatically. Webpack’s asset/inline, Vite’s ?inline import suffix, and Next.js’s next/image all auto-inline assets below a threshold. For a real codebase, configure that threshold in your bundler instead of running this tool by hand.

    When NOT to use this tool

    If your build pipeline (Webpack, Vite, Parcel, Next.js, Astro) handles inlining automatically — set the threshold in your bundler config and trust it. For batch automation in CI, write a Node script that reads the image and outputs the data URL — no browser needed. For SVG-heavy use, prefer SVG sprite sheets or inline <svg> markup over data URLs — they compress better and remain editable. Use this browser tool for one-off conversions, email templates pasted into Mailchimp/SendGrid, embed-widget config files, and learning what a data URL looks like.

    Frequently asked questions

    What’s the file size limit?

    Effectively your browser’s available memory. Conversion is fast for files up to several MB. Above 10 MB the Base64 string itself becomes unwieldy to paste. There’s no point inlining an image that large — use a CDN.

    Why does my Base64 string differ between tools?

    Same input bytes always produce the same Base64. Differences come from MIME type detection, line-break formatting (some tools insert \n every 76 characters per RFC 2045; modern tools output unbroken strings), or trailing padding. The encoded image bytes are byte-identical.

    Will inlining help my page load faster?

    For tiny critical-path images (under 4 KB, used once), yes — saves a network round-trip. For images used on multiple pages or above 10 KB, no — you bloat HTML with no caching, which is usually worse than a single fetch. Test with Lighthouse before committing.

    Does this work for SVGs?

    Yes, but a URL-encoded SVG (data:image/svg+xml;utf8,...) is usually smaller than Base64. Our converter offers both forms — pick “URL-encoded” for SVGs to save a few bytes.

    Is my image uploaded?

    No. The converter runs in your browser using the FileReader API. The image is loaded into memory and encoded locally — it never leaves your device. You can verify in the Network tab: dropping a file produces zero outbound requests.

    Can I decode Base64 back to an image?

    Yes — paste a data URL into the converter and toggle “Decode mode”. The original image is reconstructed and offered as a download. Useful for inspecting an inlined asset you want to extract from a page.

    Related tools and guides