simpletool.io Browse tools

Author: Simple Tool

  • 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

     

  • React Native Shadow Generator: iOS + Android [2026]

    React Native Shadow Generator: iOS + Android [2026]

    TL;DR: React Native handles shadows with two completely different APIs depending on platform. iOS uses four properties: shadowColor, shadowOffset, shadowOpacity, shadowRadius. Android uses one — elevation — which renders a Material-Design-style shadow whose appearance you can’t fully control. Our free React Native shadow generator shows both side by side, lets you tune iOS to match an Android elevation visually, and outputs a copy-paste StyleSheet block including the cross-platform Platform.OS guard.

    Shadows on a React Native card sound like one feature; they’re actually two implementations with no overlap. iOS reads the four shadow* props that map closely to Apple’s CALayer shadow API. Android ignores all four and reads elevation only — a 0–24 numeric value that the Material framework converts into a system-rendered shadow. Set both: iOS uses its props, Android uses elevation. Set only iOS-style props: Android is shadowless. Set only elevation: iOS is shadowless. Pretty much every “why does my shadow not show up?” Stack Overflow question is one of these three.

    Our React Native shadow generator renders both platforms side-by-side with a live preview that approximates each platform’s rendering. You set the iOS values, see the Android equivalent under our preset mapping, and copy a single StyleSheet block that works on both. This guide covers the prop semantics, the iOS-vs-Android visual mismatches, and the gotchas with backgroundColor, borderRadius, and overflow.

    iOS shadow props vs Android elevation

    Property Platform Type Default
    shadowColor iOS only colour 'black'
    shadowOffset iOS only { width, height } { width: 0, height: 0 }
    shadowOpacity iOS only number 0–1 0 (invisible)
    shadowRadius iOS only number (px) 3
    elevation Android only number (0–24) 0

    Mapping iOS values to Android elevation

    Material Design’s elevation system is a fixed scale: 1 = subtle, 2 = card, 4 = button, 6 = dropdown, 8 = floating action button, 16 = navigation drawer, 24 = highest layer. There’s no Android API to fully customise the shadow — you pick a number and Android renders the matching Material shadow. Approximate iOS-to-Android mapping:

    • iOS subtle (offset 0/2, opacity 0.1, radius 3) ≈ elevation: 2
    • iOS soft card (offset 0/4, opacity 0.15, radius 6) ≈ elevation: 4
    • iOS prominent (offset 0/6, opacity 0.2, radius 10) ≈ elevation: 8
    • iOS dramatic (offset 0/12, opacity 0.3, radius 16) ≈ elevation: 16

    Pixel-perfect parity isn’t possible — the platforms render shadows with different algorithms. Aim for visual equivalence at the design-system level: a “card” looks like a card on both platforms.

    How to generate a React Native shadow

    1. Open the React Native shadow generator
    2. Adjust the four iOS sliders: shadowColor, shadowOffset, shadowOpacity, shadowRadius
    3. The Android elevation slider tracks automatically (or override manually)
    4. Watch the side-by-side preview — iOS on the left, Android approximation on the right
    5. Click Copy StyleSheet for a complete cross-platform block

    Cross-platform StyleSheet pattern

    The standard React Native shadow shim looks like this:

    import { StyleSheet, Platform } from "react-native";

const styles = StyleSheet.create({
  card: {
    backgroundColor: "white",
    borderRadius: 12,
    padding: 16,
    ...Platform.select({
      ios: {
        shadowColor: "#000",
        shadowOffset: { width: 0, height: 4 },
        shadowOpacity: 0.15,
        shadowRadius: 8,
      },
      android: {
        elevation: 4,
      },
    }),
  },
});

    Note backgroundColor is required on Android for elevation to render — without it, Android won’t draw the shadow even though the prop is set. iOS doesn’t have this requirement.

    Common gotchas

    • Android elevation requires backgroundColor. A transparent or undefined background makes Android skip the shadow entirely. Always set a background colour for elevation to render.
    • iOS shadow doesn’t follow rounded corners by default. Set shadowPath via the older shadowOffset shape, or use the react-native-svg-shadow library if you need precision. Most cases are fine without.
    • Don’t use both elevation and iOS props on Android. elevation alone produces the Material shadow; adding iOS props doesn’t help and may break expected layouts in some RN versions.
    • shadowOpacity defaults to 0. If you set everything else but skip shadowOpacity, your iOS card has no shadow. The most common “shadow doesn’t show” cause on iOS.
    • overflow: hidden clips shadows on iOS. A card with overflow: 'hidden' (e.g., to clip an image to rounded corners) hides its own shadow. Wrap the clipped element in a parent that has the shadow, then put the clipped child inside.
    • Color names differ. iOS accepts CSS colour names; Android accepts standard names too but some hex strings render differently. Stick to hex ('#000') for cross-platform consistency.
    • RN 0.71+ supports new architecture. The new (Fabric/TurboModules) renderer respects shadow props more consistently across both platforms. Older versions (RN <0.65) may need third-party libraries like react-native-shadow-2 for visual parity.

    When NOT to use this tool

    For complex shadows (multiple stacked shadows, inner shadows, coloured shadows beyond simple offsets), use a third-party library: react-native-shadow-2 renders SVG-based shadows that look identical on both platforms. For text shadows, use the dedicated textShadowColor, textShadowOffset, textShadowRadius props (different from view shadows). For Web React Native (RN Web), neither shadow API works — use CSS box-shadow via style.shadowOffset = ... with platform check or a CSS-in-JS library.

    Frequently asked questions

    Why doesn’t my shadow show on Android?

    Three usual causes: (1) you set iOS props but no elevation — Android ignores iOS props; (2) you set elevation but the parent has no backgroundColor — Android needs an opaque background to render the shadow; (3) overflow: 'hidden' on the parent clips the shadow. Add elevation, set backgroundColor, remove overflow: hidden.

    Why doesn’t my shadow show on iOS?

    Almost always shadowOpacity is 0 (the default). Set it to 0.1–0.3. Other causes: shadowColor is transparent, parent has overflow: 'hidden', or the view has no backgroundColor (transparent views can’t cast shadows on iOS either, though it’s less strict than Android).

    Can I have a coloured shadow?

    iOS yes — set shadowColor: '#FF0000'. Android no — elevation always renders the system Material shadow which is roughly black with system-controlled opacity. For coloured shadows on Android, use react-native-shadow-2 or render a manual SVG shadow.

    Does this work on Expo and bare React Native?

    Yes. Both shadow APIs are part of core React Native; they work identically in Expo and bare projects. No native modules required.

    What’s the difference between elevation and zIndex?

    elevation controls visual shadow depth on Android. zIndex controls render order (which view appears in front). They’re independent — a high-elevation card with low zIndex still appears behind other views. Set both together when you want an elevated card to also be on top.

    Is my data uploaded?

    No. The generator runs in your browser. The shadow values, preview, and exported StyleSheet stay on your device.

    Related tools and guides

     

  • CSS Pattern Generator: Pure-CSS Backgrounds [2026]

    CSS Pattern Generator: Pure-CSS Backgrounds [2026]

    TL;DR: A CSS pattern generator outputs pure-CSS code for repeating background patterns — dots, grids, stripes, checks, isometric, halftone — with no image files needed. The technique uses repeating-linear-gradient, radial-gradient, and (modern browsers) image() + masks to draw geometric tiles directly in CSS. Result: tiny payloads (often under 100 bytes), infinite scaling, and styles that change with CSS variables. Our free CSS pattern generator ships 30+ presets with size, color, and angle controls.

    Background patterns used to mean a 1KB tileable PNG. Modern CSS makes most of them unnecessary — a dot grid is two short lines of radial-gradient; diagonal stripes are one repeating-linear-gradient; a graph-paper grid is two layered linear gradients. The CSS approach beats raster images on every axis: smaller payload, perfectly crisp on retina displays, theme-aware (use CSS variables for colors), and editable in DevTools without rebuilding assets.

    Our CSS pattern generator ships 30+ tested patterns across categories: dots (uniform dot grid, scattered, halftone), lines (horizontal, diagonal, crosshatch), grids (graph paper, isometric, hex), geometric (zigzag, chevron, scales). Adjust pattern size, foreground/background color, and angle. Outputs production-ready CSS with the canonical pattern declaration plus a fallback for older browsers.

    Pattern types and what each looks like

    Pattern Technique Best for
    Dot grid radial-gradient tile Subtle background, hero sections
    Graph paper Two linear-gradient layers Notebook / sketch UIs, illustrations
    Diagonal stripes repeating-linear-gradient Caution / warning blocks, accents
    Checkerboard Two linear-gradient layers at 45° offset Transparency indicator, retro aesthetic
    Isometric grid Three linear-gradient layers at 60° 3D illustrations, blueprint look
    Crosshatch Two diagonal repeating-linear-gradient Editorial, illustration backgrounds
    Halftone Sized radial-gradient with background-size Comic / pop-art aesthetic

    A simple dot-grid example

    The minimal CSS for a 2px dot every 24px:

    .dot-grid {
  background-color: #fffdf8;
  background-image: radial-gradient(circle, #635BFF 1px, transparent 1px);
  background-size: 24px 24px;
}

    Two lines plus background color = a perfect dot grid. Resize the background-size to change spacing, swap the colors for different themes. No image, no PNG asset, scales infinitely.

    How to generate a CSS pattern

    1. Open the CSS pattern generator
    2. Pick a pattern type from the gallery
    3. Adjust pattern size (the spacing of the repeat), foreground color, background color, and angle (where supported)
    4. Watch the live preview update across the full panel
    5. Click Copy CSS for the production-ready declaration with comments and CSS variables

    Why CSS patterns beat image tiles

    • Tiny payload. A dot grid is ~80 characters of CSS. The same as an image is 0.8–2 KB after PNG compression.
    • Infinitely scalable. A 24px tile renders crisp on a 5K display because the gradient is rasterised at the actual pixel density. PNG tiles need 2× / 3× variants for retina.
    • Theme-aware. Use CSS variables for colors and the same pattern adapts automatically to dark mode without separate assets.
    • Editable in DevTools. Tweak background-size live without rebuilding any image.
    • Server caching is irrelevant. No separate request — the pattern is part of the CSS file.

    Common gotchas

    • Performance on huge fills. A repeating-gradient pattern on a full-page background performs fine. Stacking 4+ pattern layers on the same element can slow down older mobile devices — keep complex patterns to small areas.
    • Background-attachment fixed + patterns. Using background-attachment: fixed with a CSS pattern can cause repaints on scroll. Use scroll (default) for performance unless the parallax effect is essential.
    • Patterns don’t shift with mouse / scroll. If you want a “parallax” pattern effect, you need JavaScript or transform-based motion — pure CSS patterns are static relative to their element.
    • Print stylesheets. Browsers often disable background images and patterns for print to save toner. Set -webkit-print-color-adjust: exact if printing the pattern matters.
    • Edge alignment. Pattern tiles align to the element’s background-origin. If you have padding or border-radius, the pattern continues underneath them — useful for seamless backgrounds, but watch for asymmetric clipping at corners.
    • Color overlap. When stacking multiple gradient layers (e.g., grid = horizontal lines + vertical lines), check that they blend correctly. Use the + blend mode or rgba() colors with appropriate transparency.

    When NOT to use a CSS pattern

    For organic, illustrated, or photographic patterns (watercolor textures, fabric, paper grain), use a real image — CSS gradients can’t produce non-geometric shapes. For animated patterns (slowly drifting backgrounds), use SVG with smil animations or a canvas — CSS background-position animation is choppy. For SEO-relevant images (where the pattern is content, not decoration), use a real image with proper alt text. For very complex patterns (snowflakes, paisley, custom logos repeated), use a tileable SVG instead — more efficient than 10+ stacked gradients.

    Frequently asked questions

    Are CSS patterns supported in all browsers?

    Yes — radial-gradient and repeating-linear-gradient have been supported since Chrome 26, Firefox 16, Safari 7. Universal support in 2026. Even IE 11 had partial support (no repeating gradients but solid patterns work).

    Will CSS patterns slow down my page?

    Single patterns: no — they’re rendered at GPU speed and cached. Multiple stacked patterns on the same large element can slow paint times on older mobiles, but typical use (one pattern per page) has zero measurable impact.

    Can I animate a CSS pattern?

    Limited — you can animate background-position for a “scrolling” effect, or animate background-size for pulsing. More complex animation (morphing patterns, shape changes) requires SVG or canvas. Animating background-position is GPU-accelerated and smooth.

    How do I make the pattern darker / lighter?

    Adjust the foreground and background colors directly in the CSS. Pure black/dark patterns on light backgrounds maximise contrast; semi-transparent foregrounds (e.g., rgba(0,0,0,0.05)) produce subtle textures that don’t compete with content.

    Is my data uploaded?

    No. The generator runs in your browser. Pattern selections, customisations, and the generated CSS stay on your device.

    Can I export the pattern as an image?

    Yes — there’s a “Download as PNG” option that rasterises the pattern at chosen size (256×256, 512×512, or full-screen). Useful for fallbacks in old browsers, or when an image asset is required (CMS that doesn’t accept inline CSS, email templates, etc.).

    Related tools and guides

     

  • Text to Handwriting Converter Online [2026]

    Text to Handwriting Converter Online [2026]

    TL;DR: A text-to-handwriting converter renders typed input as natural-looking handwriting on a paper background — ruled, blank, or grid. Used for journaling aesthetics, faux-handwritten letters, classroom worksheets, lecture-note mockups, and legitimate accessibility tasks (reading-disability research). Our free text-to-handwriting tool ships 12 handwriting fonts, ink colour control, paper styles, jitter (natural variation), PDF export, and a watermark to discourage misuse. Browser-only — your text never leaves your device.

    The handwritten-look aesthetic shows up everywhere — Pinterest journaling boards, Notion bullet-journal templates, Etsy printable worksheets, social-media planner mockups. Designers used to fake it by typing in a “handwriting” font in Photoshop, but native handwriting fonts placed on a digital page give themselves away: identical letters every time, perfectly aligned baselines, no ink-flow variation. Real handwriting jitters, varies pressure, drifts off the line.

    Our text to handwriting converter renders typed input on canvas with three sources of natural variation: per-letter rotation (each character tilts ±2° randomly), baseline jitter (letters drift up/down a few pixels), and ink density variation (some characters render darker than others, mimicking varying pen pressure). Add ruled-paper backgrounds, control ink colour (blue, black, red, custom), and export PNG, JPG, or PDF. This guide explains how the renderer works, when handwritten output is the right choice, and the legitimate-vs-deceptive line you mustn’t cross.

    Common use cases — and the legal line

    Use case Legitimate? Notes
    Pinterest journal mockup Yes Aesthetic content, no deception
    Faux-letter for fiction / film Yes Artistic work — clearly creative
    Tutorial / classroom example Yes Educational use, attributed
    Reading-disability research Yes Test handwriting recognition / OCR
    Skipping a handwritten assignment No Academic dishonesty in most schools
    Forging a handwritten document No Forgery — illegal in every jurisdiction
    Faking a “handwritten” doctor’s note No Document fraud, can be criminal

    The output is a digital image, not real handwriting. It will not pass a forensic handwriting-comparison test. Use it for legitimate creative work; never to deceive someone into thinking the text was actually written by hand.

    How natural variation is generated

    Real handwriting has three sources of variation our renderer reproduces:

    • Per-letter rotation: each character tilts ±0.5° to ±3° depending on the jitter slider. Without rotation, letters look stamped-on; with too much, letters look drunk.
    • Baseline drift: the y-position of each character varies ±2px. Real handwriting drifts above and below the imaginary baseline because the writer’s hand moves.
    • Pressure variation (ink darkness): each character renders at 90–100% opacity randomly. Real pen pressure produces lines of varying darkness — the renderer simulates this with per-character alpha.

    The result: same input rendered twice produces two different-looking outputs. The same letter (e.g., ‘a’) appearing five times in a sentence rotates and jitters differently each time. Click “Re-render” to shuffle the random seed and get a new variation.

    How to convert text to handwriting

    1. Open the text to handwriting converter
    2. Type or paste your text
    3. Pick a handwriting font from the 12-font library (Caveat, Patrick Hand, Indie Flower, Kalam, Shadows Into Light, etc.)
    4. Choose paper style: ruled, grid, blank, dotted, or yellow legal pad
    5. Set ink colour, jitter level, and font size
    6. Click Re-render for variation; click Export for PNG, JPG, or PDF

    Handwriting fonts and what each is for

    • Caveat: casual modern script, most popular default. Reads like a marker-on-paper note.
    • Patrick Hand: narrower, bullet-journal aesthetic.
    • Indie Flower: rounded, friendly, looks like middle-school print handwriting.
    • Kalam: Indic-script-friendly, cleaner ink lines.
    • Shadows Into Light: casual, slightly slanted, reads like quick notes.
    • Homemade Apple: messy, deliberately imperfect.
    • Sacramento: formal cursive — for “thank you” cards and wedding invitations.
    • Permanent Marker: bold marker style — for poster mockups.
    • Just Another Hand: condensed letters, fast-handwriting feel.
    • … 3 more for variety.

    Common gotchas

    • Real handwriting recognition isn’t fooled. An OCR system or a forensic handwriting analyst will identify generated handwriting instantly — letter-frequency analysis, consistent stroke patterns, and font-rendering artefacts give it away. Don’t expect this to fool any system that examines handwriting.
    • Long passages take a while. Rendering each character individually with per-character rotation is slow. A single page of text (~250 words) takes 1–3 seconds; a full essay (1,500+ words) can take 10–20 seconds. Break long content into pages and export per-page PDFs.
    • Cursive fonts can be hard to read. Sacramento and similar formal-cursive fonts look elegant but reduce reading speed by 30%+ for typical readers. Use casual print-style fonts (Caveat, Patrick Hand) for readability; cursive for aesthetic-only mockups.
    • Paper texture is procedural. The “ruled paper” background isn’t a high-res scan — it’s drawn at render time. Export at higher resolution (2× or 3×) for print; lower resolutions make the texture look obviously digital.
    • Ink colour interacts with paper. Black ink on yellow legal-pad paper looks fine; light blue ink on white paper looks washed out. Match ink colour to paper for legible output.
    • Special characters render inconsistently. Some handwriting fonts don’t include glyphs for em-dashes, smart quotes, or accented characters — they fall back to a default font, breaking the handwritten illusion. Stick to ASCII for the most consistent look.

    When NOT to use this tool

    For real handwriting practice (improving your own handwriting), use a handwriting workbook — a generator can’t help. For accessibility tools that need true handwritten outputs, use an iPad-with-Apple-Pencil workflow. For commercial use of the output (selling printables on Etsy, using in client deliverables), check the licensing of each handwriting font — most Google Fonts are SIL Open Font Licence (free for commercial), but custom fonts may have restrictions. For document forgery or any use that misleads someone — don’t use this tool, full stop. The output is intended for legitimate creative and educational work.

    Frequently asked questions

    Will this fool a teacher / professor?

    Probably not, and don’t try — it’s academic dishonesty. The output is digital with consistent letter shapes that an experienced grader spots quickly. Use the tool for creative projects, mockups, and presentations — not to skip handwritten assignments.

    Can I use my own handwriting font?

    Yes — upload a custom font file (TTF or WOFF). Some users digitise their own handwriting using services like Calligraphr (free for one font) and upload the result for genuinely personal handwriting output.

    What’s the difference between a handwriting font and this tool?

    A static font renders every ‘a’ identically — gives away that it’s typed. This tool adds per-character rotation, baseline jitter, and pressure variation, so the same letter looks different each time it appears. Same starting font; much more natural-looking output.

    Can I export at high resolution for print?

    Yes — pick 2× or 3× resolution before export. PDF output is vector for the paper rules but raster for the rendered text (at 300 DPI by default). For poster-size print, export at 4× and downscale slightly in your print software.

    Is my text uploaded?

    No. The renderer uses canvas in your browser. Your text, the font choice, and the exported image all stay on your device — never sent to our servers.

    Can I batch-render many pages?

    Yes — paste multi-page text and the tool paginates automatically (using a page-break marker or after N lines). Export produces a multi-page PDF or a ZIP of PNG files, one per page.

    Related tools and guides

     

  • CSS Triangle Generator: Border Trick + Clip-Path [2026]

    CSS Triangle Generator: Border Trick + Clip-Path [2026]

    TL;DR: CSS triangles use one of two techniques: the classic border trick (a zero-size element with thick transparent borders, where one border has a color — that color shows as a triangle) or modern clip-path with a polygon(). Border trick has perfect browser support back to IE 6; clip-path is cleaner CSS but needs a real-sized box. Our free CSS triangle generator outputs both forms with size, color, and direction controls.

    CSS triangles solve a specific problem: drawing a small triangular shape (tooltip arrows, dropdown indicators, breadcrumb separators, accent shapes) without an SVG or image. The two techniques have been around forever — the border-trick variant is famously hacky CSS that works because of how browsers render border miters at the corners of an element. The clip-path variant is straightforward but needs more recent browser support.

    Our CSS triangle generator builds either form. Pick a direction (up, down, left, right, or one of four diagonals), set size and color, and copy the production CSS. Both versions are inline-able — no extra HTML elements needed beyond the triangle’s own div or span. This guide explains both techniques, when to use which, and the rendering quirks that make one or the other choice for specific contexts.

    Border trick vs clip-path — which to use

    Technique Pros Cons
    Border trick Universal browser support; zero-size element Hard to gradient-fill; smaller hit area
    clip-path polygon() Cleaner CSS; can have content; gradient-fillable Modern only; needs real-size box

    For tooltip arrows and dropdown indicators (decoration only): use the border trick. For triangular badges, decorative shapes, or any triangle that needs gradients, text inside, or animation: use clip-path.

    The border-trick technique explained

    An element with width: 0; height: 0; and thick borders renders as four diagonal-mitered triangles meeting at the centre. Make three of those borders transparent and you’re left with a single triangle in the colour of the visible border:

    /* Triangle pointing up — 30px wide, 20px tall */
.triangle-up {
  width: 0;
  height: 0;
  border-left: 15px solid transparent;
  border-right: 15px solid transparent;
  border-bottom: 20px solid #635BFF;
}

/* Triangle pointing down */
.triangle-down {
  width: 0;
  height: 0;
  border-left: 15px solid transparent;
  border-right: 15px solid transparent;
  border-top: 20px solid #635BFF;
}

    The size is implicit: the triangle’s width is twice the border-left/right width (30px above), and its height is whatever the visible border thickness is (20px). To change direction, change which border is solid and which are transparent.

    The clip-path technique explained

    A real-sized div clipped to a polygon shape produces an editable, fill-able triangle:

    /* Triangle pointing up */
.triangle-up {
  width: 60px;
  height: 60px;
  background: #635BFF;
  clip-path: polygon(50% 0%, 100% 100%, 0% 100%);
}

/* Add gradient or border easily */
.triangle-gradient {
  width: 60px;
  height: 60px;
  background: linear-gradient(45deg, #635BFF, #00D4FF);
  clip-path: polygon(50% 0%, 100% 100%, 0% 100%);
}

    Bonus: clip-path triangles can have text inside (it’s a real div), can be flex/grid containers, and can be animated. The cost is needing modern browser support (Chrome 23+, Firefox 54+, Safari 7+ — universal in 2026 except IE).

    How to generate a CSS triangle

    1. Open the CSS triangle generator
    2. Pick direction (up, down, left, right, top-left/top-right/bottom-left/bottom-right diagonals)
    3. Set width and height
    4. Pick color, plus a stroke for the clip-path version
    5. Toggle between Border trick and clip-path output
    6. Click Copy CSS

    When you’d use a triangle in real CSS

    • Tooltip arrows. A triangle pointing at the trigger element. The classic use — small (8–12px), border-trick, positioned absolutely against the tooltip body.
    • Dropdown carets. The little ▼ next to “More” buttons. Often replaced by SVG icons in modern UIs but still common in plain-CSS contexts.
    • Breadcrumb separators. The “›” between items. Often a real character, but a CSS triangle gives precise control over color and angle.
    • Speech-bubble pointers. Chat-bubble UIs use a triangle pointing at the speaker. Border trick or clip-path both work.
    • Decorative section dividers. A wide, flat triangle as a wedge between page sections. Use clip-path on a full-width div for this.
    • Custom badges. Triangular accent on the corner of a card. clip-path with text inside.

    Common gotchas

    • Sub-pixel rendering. Triangles smaller than 8px can look blurry on non-retina displays because the diagonal isn’t a clean pixel boundary. Either use larger triangles or accept slight anti-aliasing artefacts.
    • Background colour bleeds. The transparent borders in the border trick still occupy hit-test area. The visible triangle’s clickable region extends to the full bounding box, not just the visible part.
    • Inline element issues. A border-trick triangle on a <span> may render with line-height padding around it. Use display: inline-block or wrap in a container.
    • Right-to-left layouts. A triangle pointing “left” should flip to point “right” in RTL layouts. CSS logical properties (margin-inline-start etc.) help, but border-direction names don’t have logical equivalents — handle the flip manually with [dir="rtl"] selectors.
    • Animation cost. Border-trick triangles can be expensive to animate (changing border width triggers layout). clip-path triangles animate cheaply (transform-only).
    • Don’t try to gradient-fill a border-trick triangle. Borders take a single solid color. For gradients, use clip-path; for the border trick, use a wrapper element with the gradient and the triangle as a mask.

    When NOT to use a CSS triangle

    For complex shapes (chevron with rounded corners, triangular logos, multi-color triangles), use SVG inline — much more flexible. For a triangle with shadows, drop-shadow, or stroke effects, use clip-path with filter: drop-shadow(). For very tiny triangles (under 4px), consider Unicode characters (▲ ▼ ◀ ▶) which are font-rendered and crisp at small sizes. For animated character indicators (like a pulse arrow), an SVG with proper SVG animations is smoother than a CSS-only approach.

    Frequently asked questions

    Why does the border trick work?

    Browsers render borders with diagonal miters at corners. An element with zero width and height is just a point — the corners meet at the centre — and each border becomes a triangle pointing inward. Make three transparent and one solid coloured, and you see only the solid triangle.

    Which technique should I use?

    For tooltip arrows and small UI triangles: border trick (universal support, simpler positioning). For decorative triangles with content, gradients, or animation: clip-path. Both are universally supported in 2026 except IE (retired).

    Can I make a triangle with rounded corners?

    Not with the border trick. With clip-path, the polygon corners are sharp by default — for rounded triangles, use SVG with stroke-linejoin or a custom path. There’s a CSS proposal for shape-radius but it’s not implemented yet.

    How do I rotate a triangle?

    For arbitrary angles, generate a “pointing-up” triangle and apply transform: rotate(45deg). The triangle rotates around its centre. Combine with transform-origin to rotate around a different point.

    Is my data uploaded?

    No. The generator runs in your browser. Triangle settings, the live preview, and the generated CSS stay on your device.

    Can I have text inside a CSS triangle?

    Yes — only with the clip-path version. The border-trick triangle has zero width and height, so no content fits. clip-path triangles are real divs with full layout properties — text, flex, grid, anything.

    Related tools and guides

     

  • CSS Checkbox Generator: Custom Style, Accessible [2026]

    CSS Checkbox Generator: Custom Style, Accessible [2026]

    TL;DR: A CSS checkbox generator outputs custom-styled checkboxes that wrap a native <input type="checkbox"> for accessibility — keyboard navigation, screen reader announcements, form-submit semantics — while letting you control every visual aspect. The technique uses appearance: none to strip the default style, then renders a custom check via ::before pseudo-element. Our free CSS checkbox generator ships 20+ presets (rounded, bordered, animated, brand-colored), custom check icons, and the indeterminate state.

    HTML checkboxes look the same on every site by default — and every site replaces them. Bootstrap, Tailwind UI, Material Design, every CMS, every shadcn-ui clone has a custom checkbox component. The challenge isn’t visual — it’s keeping the accessibility intact while restyling. A custom div-based checkbox loses keyboard support, form submission, screen-reader announcements, and pointer-events behaviour. The trick: keep the native <input> for accessibility, hide it visually, and style a sibling element that responds to its state.

    Our CSS checkbox generator outputs the canonical pattern: a hidden native input + an associated label with a custom-styled box. Keyboard Space still toggles, Tab still navigates, screen readers still announce “checkbox, checked”, and the form still submits the value. This guide explains the accessibility-preserving CSS pattern, the gotchas with :focus-visible rings, and how to add the indeterminate state correctly.

    The accessibility-preserving CSS pattern

    The pattern uses appearance: none on the input to strip default OS styling, then customises every visual aspect with CSS — without losing the underlying <input>:

    input[type="checkbox"] {
  appearance: none;
  -webkit-appearance: none;
  width: 24px;
  height: 24px;
  border: 2px solid #d0d5dd;
  border-radius: 6px;
  background: white;
  cursor: pointer;
  position: relative;
  transition: all 150ms ease;
}

input[type="checkbox"]:checked {
  background: #635BFF;
  border-color: #635BFF;
}

input[type="checkbox"]:checked::after {
  content: "";
  position: absolute;
  inset: 4px 6px;
  border-right: 2px solid white;
  border-bottom: 2px solid white;
  transform: rotate(45deg);
}

input[type="checkbox"]:focus-visible {
  outline: 2px solid #635BFF;
  outline-offset: 2px;
}

    That’s it — a fully custom-styled checkbox with keyboard support, form support, and accessibility intact. The native <input> still receives focus, still toggles on space, still submits. appearance: none works in every modern browser since 2020.

    Visual variations and presets

    Preset Look Best for
    Rounded square 8px corner radius (default in 2026 design) Modern web apps
    Sharp square No radius Brutalist or technical UIs
    Circle 50% radius — like a radio button Soft, friendly UIs
    Animated check Stroke-dash animation on toggle Premium feel
    Material ripple Tap-feedback ripple animation Material Design apps
    iOS-style Filled fill on check iOS-feel UIs

    How to generate a custom checkbox

    1. Open the CSS checkbox generator
    2. Pick a preset shape (rounded square, sharp, circle)
    3. Set border color, fill color, check icon style
    4. Toggle features: animation, ripple, indeterminate-state support, focus ring style
    5. Click Copy CSS for the production code (includes :focus-visible for accessibility)

    The indeterminate state — what most generators skip

    HTML checkboxes have three states: unchecked, checked, and indeterminate. Indeterminate is set programmatically (via JavaScript: el.indeterminate = true;) and represents “partially selected” — common in tree views where a parent is partially-but-not-fully checked among children.

    The CSS selector for indeterminate is :indeterminate. Our generator outputs a third visual state for it (typically a horizontal bar instead of a checkmark):

    input[type="checkbox"]:indeterminate {
  background: #635BFF;
  border-color: #635BFF;
}

input[type="checkbox"]:indeterminate::after {
  content: "";
  position: absolute;
  left: 4px;
  right: 4px;
  top: 50%;
  height: 2px;
  background: white;
  transform: translateY(-50%);
}

    Common gotchas

    • Don’t replace the input with a div. Common mistake: hide the input entirely and use a custom <div> for the visual. You lose all accessibility — keyboard nav, screen-reader, form submit. Always keep the real input and style it.
    • :focus-visible vs :focus. Use :focus-visible for the focus ring — it shows only on keyboard focus, not on click. Without this, every click also shows the focus ring, which looks bad. :focus-visible is supported everywhere except the very oldest browsers.
    • Disabled state. A custom checkbox needs :disabled styling — usually 50% opacity and cursor: not-allowed. Don’t forget this state; users who don’t notice a disabled checkbox will tap it repeatedly in frustration.
    • Hover-only feedback isn’t enough. Touch users don’t have hover. Make sure your checked / unchecked / focus states all work without depending on hover.
    • Don’t forget the label. A bare checkbox without a label is unusable for screen readers. Wrap your checkbox + text in a <label> or use aria-labelledby. Most accessibility audits flag missing checkbox labels first.
    • iOS Safari and -webkit-appearance. Older Safari needs -webkit-appearance: none alongside appearance: none. Both prefixes work in Safari 14+; for iOS 12 and below, you need -webkit-appearance first.

    When NOT to use a CSS checkbox

    For toggle switches (on/off), use a switch component instead — visually different from checkboxes, semantically same. For radio buttons (mutually exclusive options), use type="radio" with the same custom-CSS pattern. For custom multi-select UIs (chip-style filters, tag pickers), button + aria-pressed is more appropriate than a checkbox. For very heavy custom interactions (slider toggles with drag gestures), a JS-driven component beats CSS-only — but for the 95% case, the native checkbox + custom CSS is the right call.

    Frequently asked questions

    Will custom CSS break accessibility?

    Not if you keep the native <input type="checkbox">. The element handles all accessibility — keyboard, screen reader, form submission. Hide its default visual with appearance: none and style it. Don’t replace the input with a div.

    Does this support the indeterminate state?

    Yes — set via JavaScript (checkbox.indeterminate = true) and styled via the :indeterminate CSS pseudo-class. Our generator outputs a third visual state for indeterminate (typically a bar instead of a checkmark).

    How do I make the focus ring keyboard-only?

    Use :focus-visible instead of :focus. :focus-visible only triggers on keyboard navigation, not on click. Supported in Chrome 86+, Firefox 85+, Safari 15.4+ — universal in 2026.

    Can I animate the check appearing?

    Yes — animate the ::after pseudo-element’s transform or stroke-dasharray. Generator presets include “animated check” with stroke-dashoffset that draws the checkmark on toggle. Performance is fine for hundreds of checkboxes.

    Is my data uploaded?

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

    What’s the difference between a checkbox and a switch?

    Semantically the same (binary on/off), visually different. Checkboxes are for forms with multiple selections (filter lists, terms-acceptance). Switches are for settings that take effect immediately (notifications on/off, dark mode). Native HTML doesn’t have a switch — use a checkbox + ARIA role="switch" for the same accessibility behaviour with switch styling.

    Related tools and guides

     

  • SVG Pattern Generator: Tileable Backgrounds [2026]

    SVG Pattern Generator: Tileable Backgrounds [2026]

    TL;DR: An SVG pattern generator outputs tileable SVG graphics — repeating shapes (dots, triangles, hexagons, lines, scales) that can be used as background-image fills. SVG patterns scale infinitely, accept custom colors via CSS variables, and produce smaller payloads than equivalent PNG tiles for most cases. Our free SVG pattern generator ships 60+ tested shapes, exports as standalone SVG, PNG raster, or CSS data URL — ready to drop into any stylesheet.

    For repeating decorative backgrounds, the choice in 2026 is between three approaches: pure CSS gradients (smallest, geometric only), SVG patterns (vector-perfect, complex shapes), or PNG tiles (legacy fallback). SVG wins when your shape is anything more complex than dots and stripes — hexagonal grids, isometric blocks, scaled fish-scales, abstract logos repeated. SVG patterns are also CSS-variable-friendly: change a single CSS custom property and the entire tiled pattern re-colors without regenerating the asset.

    Our SVG pattern generator ships 60+ tested patterns with size, color, and density controls. Outputs three forms: standalone .svg file (use as background-image: url(...)), Base64 data URL (inline in CSS), or PNG export (legacy fallback). Patterns are seamless — the right edge meets the left edge cleanly, the top meets the bottom — so any tile size repeats without visible seams. This guide explains how SVG patterns are constructed, when SVG beats CSS or PNG, and the gotchas with anti-aliasing at tile boundaries.

    SVG vs CSS vs PNG patterns

    Approach File size Best for
    CSS gradient ~80 bytes Dots, lines, stripes, simple grids
    SVG pattern 300-1500 bytes Triangles, hexagons, complex shapes, custom logos
    PNG tile 2-15 KB per tile Photographic textures, complex non-geometric

    If your pattern can be expressed as gradients (dots, lines, grids), use CSS — smallest payload. If it’s geometric but more complex than gradients allow (triangles, hexagons), use SVG. If it’s photographic or organic (paper texture, fabric weave), use PNG.

    SVG pattern anatomy

    A typical SVG pattern is a repeating tile defined inside a <defs> block, then referenced as a fill:

    <svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%">
  <defs>
    <pattern id="dots" x="0" y="0" width="20" height="20" patternUnits="userSpaceOnUse">
      <circle cx="10" cy="10" r="2" fill="#635BFF"/>
    </pattern>
  </defs>
  <rect width="100%" height="100%" fill="url(#dots)"/>
</svg>

    The <pattern> element defines a 20×20 tile with a single circle at the centre. The outer rectangle fills the entire SVG with that pattern. Change pattern dimensions, fill colour, or geometry — the pattern updates automatically.

    How to generate an SVG pattern

    1. Open the SVG pattern generator
    2. Pick a shape from the gallery (60+ options across 5 categories)
    3. Adjust tile size, foreground color, background color, and density
    4. Watch the live preview render the seamless tile
    5. Export: standalone SVG file, Data URL (CSS-ready), or PNG rasterized at chosen resolution

    Using SVG patterns as CSS backgrounds

    Two ways to include an SVG pattern in CSS:

    • External file: background: url("/patterns/dots.svg") repeat; — saves a separate request, cacheable, scales with browser zoom.
    • Inline data URL: background: url("data:image/svg+xml;utf8,<svg...>") repeat; — no extra request, theme-able with CSS variables.

    For one-off patterns, inline data URLs save a round-trip; for patterns reused across many pages, external files cache better. For maximum flexibility, use a CSS variable for the pattern’s primary color: the data URL references it via fill="currentColor" or accepts injected colors via background-image stacking.

    60+ shapes shipped with the generator

    • Dots: uniform grid, scattered, halftone, polka, large/small mix
    • Triangles: equilateral, scalene, isometric grid, chevron, sawtooth
    • Hexagons: honeycomb, beehive, isometric, soccer-ball-style
    • Lines: diagonal, crosshatch, sketchy, double-line, wave
    • Scales: fish, dragon, oversized, miniature
    • Geometric: circles, squares, plus signs, asterisks, stars, arrows
    • Floral: abstract flower tile, art-deco fan
    • Tech: circuit traces, schematic, blueprint grid

    Common gotchas

    • Anti-aliasing at seams. If your shape touches the edge of the tile, anti-aliasing can produce visible vertical or horizontal lines where tiles meet. Add 1px padding inside the tile (so shapes don’t touch the edge) or use SVG’s shape-rendering: crispEdges.
    • Data URLs need careful escaping. Inline SVG in CSS data URLs needs URL encoding (%, #, ", etc.). Use ? as a safe alternative for < if your CSS toolchain breaks. Our generator outputs already-escaped data URLs.
    • Vector but not infinite. SVG patterns scale with display zoom but the pattern tile size is fixed in the generator output. To make tiles scale with viewport, use CSS background-size: 5vw 5vw or similar — but that distorts the pattern.
    • Custom fonts in patterns don’t work. If your pattern uses text glyphs (e.g., a tiled “★” character), include the font definition inline via @font-face in the SVG itself, or use SVG path data for the character. External font files won’t load in SVG-as-image contexts.
    • Pattern size affects performance. Tiny tiles (under 8×8) render slower than larger ones because the GPU has to repeat them more times. For very fine patterns, use a 32×32 tile with multiple instances inside.
    • Background-attachment: fixed + SVG patterns. Patterns repeat strangely with background-attachment: fixed on some browsers. Test before deploying parallax-style background effects.

    When NOT to use an SVG pattern

    For simple geometric patterns (dots, lines, grids), use CSS gradients — smaller payload, same effect. For photographic or organic textures (paper, fabric, watercolor), use a PNG with proper compression. For animated patterns (drifting, morphing), use a CSS animation on the SVG itself or a canvas-based approach. For very large patterns where the tile is 1000×1000+, you’re better off with a real image — at that size SVG offers no advantage over PNG. For extremely tight performance budgets, even a small SVG pattern adds 500–1500 bytes; CSS gradients add 80.

    Frequently asked questions

    Are SVG patterns faster than PNG?

    For most simple shapes: yes, smaller and faster. For very complex patterns or photographic-quality textures: no, PNGs (especially WebP or AVIF) compress better. Rule of thumb: if the pattern is geometric, SVG; if it’s organic, raster.

    Can I edit the SVG pattern after generating?

    Yes — the output is plain SVG markup. Open in any text editor, change fill values, adjust shapes inside the <pattern>, scale the tile dimensions. Or import into Figma / Illustrator / Inkscape for visual editing.

    Will the pattern look the same on retina displays?

    Yes — SVG is vector, so it renders pixel-perfect at any DPI. PNG patterns need 2× / 3× variants for retina; SVG doesn’t.

    Can I use CSS variables for pattern colors?

    Inside an SVG file referenced via external URL, CSS variables don’t propagate. For inline data URLs in your CSS, use currentColor in the SVG fills, then set color on the parent element to control the pattern’s primary color. For full theme support, generate the pattern programmatically and inject CSS variable values.

    Is my data uploaded?

    No. The generator runs in your browser. Pattern selections, customisations, and the generated SVG/PNG/data URL stay on your device.

    Can I use these patterns commercially?

    Yes — the generated SVG is your output, no attribution required. The shape templates are designed for any use including commercial work. The exception: if you upload your own custom shape and the original asset has licensing restrictions, those carry over to the generated pattern.

    Related tools and guides