Category: Design Tools

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

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

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

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

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

    Switch vs checkbox — when to use which

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

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

    The accessible CSS switch pattern

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

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

    Visual presets

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

    How to generate a CSS switch

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

    Common gotchas

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

    When NOT to use a CSS switch

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

    Frequently asked questions

    Switch or checkbox — what’s the difference?

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

    Will custom CSS break accessibility?

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

    Is role=”switch” supported by screen readers?

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

    How do I prevent accidental toggles?

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

    Is my data uploaded?

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

    Can I animate the switch differently?

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

    Related tools and guides

     

  • CSS Glitch Effect: Cyberpunk Text Animation [2026]

    CSS Glitch Effect: Cyberpunk Text Animation [2026]

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

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

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

    Glitch effect anatomy

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

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

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

    Glitch presets and what each looks like

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

    How to generate a glitch effect

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

    Accessibility — glitch effects can cause harm

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

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

    Common gotchas

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

    When NOT to use a glitch effect

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

    Frequently asked questions

    Will the glitch effect work in all browsers?

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

    Can I disable the animation for accessibility?

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

    Does the glitch effect break SEO?

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

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

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

    Is my data uploaded?

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

    How do I customise the glitch colours?

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

    Related tools and guides

     

  • SVG Blob Generator: Random Organic Shapes [2026]

    SVG Blob Generator: Random Organic Shapes [2026]

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

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

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

    When blobs work — and when they don’t

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

    How blob shapes are generated (the algorithm)

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

    Two parameters control the look:

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

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

    How to generate a blob in your browser

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

    SVG output anatomy — what you’ll paste

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

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

    Common gotchas

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

    When NOT to use a blob

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

    Frequently asked questions

    Can I edit the blob after generating?

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

    Will the same seed produce the same blob across browsers?

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

    Can I animate between two blobs?

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

    Should I use SVG or PNG?

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

    Is my data uploaded?

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

    Can I use blobs in print or for stickers?

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

    Related tools and guides

     

  • JavaScript Formatter: Beautify JS with Prettier [2026]

    JavaScript Formatter: Beautify JS with Prettier [2026]

    TL;DR: A JavaScript formatter (also called a beautifier) reformats messy or minified JS into consistently-indented, readable code. Our free JavaScript formatter runs Prettier 3 in your browser — the same engine 80%+ of professional JS teams ship — with full TypeScript and JSX support, configurable print width, semis, and quote style. No upload, paste any size.

    Inconsistent formatting is the silent productivity tax of every codebase. Two engineers who disagree about semicolons or trailing commas will spend more time arguing about diffs than fixing bugs. The industry settled this argument in 2017 when Prettier shipped: pick a config once, run the formatter on save, and the rest is mechanical. By 2026, Prettier is the default formatter in VS Code, the default in Next.js / Remix / Vite scaffolds, and a hard requirement on most engineering teams.

    Our JavaScript formatter runs Prettier 3 in your browser via WebAssembly. It handles JavaScript (ES2024), TypeScript, JSX, TSX, JSON, and Markdown code blocks. Use it to beautify a one-liner you copied from a build output, to reformat code from a tutorial that uses different indentation than your project, or to apply Prettier without installing anything. This guide covers every option, the differences vs Beautify.js, and when to use a formatter vs a minifier.

    Prettier options that matter (and the defaults to start with)

    Option Default When to change
    printWidth 80 100 or 120 if your team uses wide monitors
    tabWidth 2 4 only if you write Java/C# style or for accessibility
    useTabs false true for accessibility (screen readers can adjust width)
    semi true false if your team writes Standard JS / no-semi style
    singleQuote false true for most codebases (preferred by Airbnb / Standard)
    trailingComma “all” “es5” if targeting old browsers (rare in 2026)
    bracketSpacing true false to compress (against the Prettier philosophy)
    arrowParens “always” “avoid” if your style guide forbids parens around single arrow args

    The defaults are deliberately opinionated. Prettier’s design philosophy is “you don’t get to choose 30 micro-options” — pick a print width and a quote style and stop bikeshedding. Most teams adjust at most 3 fields.

    Prettier vs Beautify.js vs ESLint –fix

    • Prettier: opinionated, fast, only handles formatting (no logic). Makes formatting a non-decision.
    • Beautify.js: the older formatter (jsbeautify). More configurable, less consistent. Still acceptable for one-off cleanup but hasn’t been the team standard since 2018.
    • ESLint –fix: a linter that can reformat. Powerful but slower than Prettier and requires you to author the rules. Most teams run ESLint and Prettier — Prettier handles whitespace, ESLint handles correctness (unused vars, missing await).
    • Editor-only: VS Code’s built-in formatter is OK for ad-hoc edits but doesn’t enforce a project-wide style.

    Use Prettier for production code; use this browser tool for one-off snippets where installing Prettier locally is overkill.

    How to format JavaScript in your browser

    1. Open the JavaScript formatter
    2. Paste your code (works for JS, TS, JSX, TSX, JSON)
    3. Pick parser (auto-detect usually works) and adjust print width, semis, quotes
    4. Click Format — output appears with syntax highlighting
    5. Click Copy or Download

    TypeScript and JSX formatting (the parser matters)

    Prettier auto-detects in most cases, but ambiguity is real: <Foo>bar</Foo> is JSX in a .jsx file and a TypeScript type assertion in a .ts file. Tell the formatter explicitly which parser to use:

    • babel — JS with JSX (default for most React code)
    • typescript — TS without JSX
    • babel-ts — TS with JSX (TSX files)
    • json — JSON / JSON5 / package.json
    • flow — Facebook’s Flow type annotations (declining usage)

    Picking the wrong parser produces silent failures — Prettier returns the input unchanged. If formatting “did nothing”, switch the parser.

    Common gotchas

    • Don’t format generated code. If a file ends in .min.js, don’t re-format it — variable names are mangled, formatting won’t recover them, and you’ll bloat your repo with un-debuggable output.
    • Prettier won’t fix logic. Missing semicolons in ASI-trap positions (return\n[1,2,3]) get a semicolon inserted — the code’s behaviour stays “broken”. Use ESLint’s no-unreachable for those.
    • Magic strings inside string templates aren’t formatted. Code inside template literals (`code goes here`) is treated as a string. To format embedded code, extract it.
    • JSON allows trailing commas only with parser “json5”. Standard JSON doesn’t permit them. The default json parser strips trailing commas.
    • Prettier 3 changed defaults from Prettier 2. trailingComma default went from "es5" to "all". If you regenerate a file with v3 and check it in, expect comma-only diff noise.
    • Auto-format on save can fight version control. If two devs use different Prettier versions, every save generates noise. Pin a version with "prettier": "3.x" in your package.json and commit the .prettierrc.

    When NOT to use a browser formatter

    For a real codebase, install Prettier locally (npm i -D prettier), commit a .prettierrc, and configure your editor to format on save. That gives every collaborator the same output and removes formatting from code review entirely. Use this browser tool for one-off snippets, code from a tutorial that disagrees with your style, copy-paste from build logs, or quick previews of how Prettier would render code in a project that doesn’t have it set up yet.

    Frequently asked questions

    Does this support TypeScript and JSX?

    Yes. The formatter ships Prettier 3 with all the standard parsers: babel (JS+JSX), typescript (TS), babel-ts (TSX), json, and flow. Auto-detect picks the right parser from the file extension when you upload, or you can override the parser manually for paste-mode.

    Can I save my Prettier config?

    Settings persist in your browser’s localStorage between sessions. There’s also a “Copy as .prettierrc” button that exports your settings as a JSON file ready to drop into a project root.

    What’s the difference between formatting and minifying?

    Opposite jobs. Formatting adds whitespace and indentation for readability (build-time → editor view). Minifying removes whitespace and renames variables to shrink file size (editor → build → CDN). Use a formatter while you’re writing code; use a minifier as the last step before deploy.

    Can I format minified code back into readable code?

    Partially. Whitespace and indentation are restored; structure is recovered. But variable names that were mangled to a, b, c stay mangled — that information is gone unless you have the original source map. Use this for “what does this function do?”-grade reverse engineering, not for full source recovery.

    Is my code uploaded?

    No. Prettier runs in your browser via WebAssembly. Code is never uploaded to our servers — safe for proprietary, pre-release, or sensitive code.

    What’s the size limit?

    Effectively your browser’s available memory. Prettier handles files of several MB without trouble; very large files (10K+ lines) can take 2–5 seconds. For batch formatting of many files, use Prettier locally via npx prettier --write instead.

    Related tools and guides

     

  • Cubic Bezier Generator: CSS Easing Curves [2026]

    Cubic Bezier Generator: CSS Easing Curves [2026]

    TL;DR: CSS cubic-bezier() defines a custom easing curve for transitions and animations using four numbers — the X and Y of two control handles. cubic-bezier(0.25, 0.1, 0.25, 1) is the default “ease” keyword. Our free cubic-bezier generator ships a draggable visual editor, a live ball-and-square animation that plays the curve, and 14 named presets (ease, ease-in, ease-out, plus the Material Design and iOS spring curves).

    The default CSS easing keyword (ease) starts slow, accelerates, then slows down — fine for most quick state transitions, but bland for hero animations and microinteractions. cubic-bezier() lets you define an easing curve precisely. Drag the curve to start fast and end slow, overshoot the target, anticipate before moving, or stay still then snap into place. The right easing turns a generic UI into one that feels intentional.

    The challenge is that bezier coordinates are unreadable. cubic-bezier(0.4, 0, 0.2, 1) is Material Design’s standard curve. cubic-bezier(0.68, -0.55, 0.265, 1.55) is “back” easing with overshoot. You can’t picture either by reading the numbers. Our cubic-bezier generator shows the curve graphically with two draggable handles, animates a sample element with each curve change, and outputs the CSS in real time.

    The 14 named presets and what they feel like

    Preset Bezier values Feel
    linear 0, 0, 1, 1 Constant speed — for indeterminate spinners
    ease 0.25, 0.1, 0.25, 1 Default — smooth, slightly weighted near end
    ease-in 0.42, 0, 1, 1 Slow start, fast end — for elements leaving
    ease-out 0, 0, 0.58, 1 Fast start, slow end — for elements entering
    ease-in-out 0.42, 0, 0.58, 1 Symmetric — for back-and-forth movement
    Material Standard 0.4, 0, 0.2, 1 Material Design 3 default
    iOS Default 0.25, 0.46, 0.45, 0.94 Native iOS feel — close to ease-out
    Back (overshoot) 0.68, -0.55, 0.265, 1.55 Anticipates and overshoots — playful
    Snap 0.9, 0, 0.1, 1 Holds, then snaps in — for confident states

    How the curve works (in human terms)

    The four numbers in cubic-bezier(x1, y1, x2, y2) are the X and Y of two control handles between the start (always 0,0) and end (always 1,1) of the curve. The X axis is time (0 = start, 1 = end of the duration). The Y axis is progress (0 = initial position, 1 = final position). The handles pull the curve in the direction of their position — drag a handle up and the curve overshoots; drag it down and the curve eases.

    X must be between 0 and 1; Y can go above 1 (overshoot) or below 0 (anticipate). The visual editor enforces the X constraint and lets Y go outside the box for those expressive curves.

    How to design a bezier curve in your browser

    1. Open the cubic-bezier generator
    2. Pick a preset (or start from ease) and drag the two handles to shape the curve
    3. Watch the live preview — a square moves left-to-right with the easing applied
    4. Adjust the duration (250ms to 2s) and the curve in tandem to land on the right feel
    5. Click Copy CSS to grab the transition-timing-function declaration

    Where the bezier value goes in real CSS

    Two places use it: transition-timing-function and animation-timing-function. Inside the transition shorthand:

    .button {
      transition: transform 250ms cubic-bezier(0.4, 0, 0.2, 1);
    }
    .button:hover {
      transform: translateY(-2px);
    }

    For keyframe animations, set the timing function on the animation as a whole or per keyframe (@keyframes entries can have their own timing function for staged easing).

    Common gotchas

    • linear-with-overrides for staged motion. If you need different easing per phase of an animation, use linear() (CSS Easing 2 — Chrome 113+) which lets you describe a polyline of stops, or chain multiple keyframes with their own timing functions.
    • Overshoot Y values can break perceived motion. A curve with Y > 1 returns the element past its target, then back. For “natural” overshoot, keep the second Y between 1.05 and 1.2; higher than 1.5 looks cartoony.
    • Don’t animate top, left, or width. These trigger layout. Always animate transform and opacity for 60fps performance, regardless of the easing curve.
    • iOS spring physics aren’t bezier curves. Native iOS uses spring-physics easing (mass, stiffness, damping). The closest CSS approximation is cubic-bezier(0.25, 0.46, 0.45, 0.94) for the standard iOS feel, but real spring curves bounce; bezier curves don’t.
    • steps() is not bezier. The steps() timing function produces discrete jumps for sprite animations. It’s a different family from cubic-bezier() — pick one based on whether you want continuous motion or a frame-by-frame walk cycle.
    • Match curve to direction. Use ease-out for elements entering the viewport (they decelerate into place); use ease-in for elements leaving (they accelerate away). Symmetric curves (ease, ease-in-out) are best for scrubbed timelines and back-and-forth states.

    When NOT to use cubic-bezier

    For physical-feeling spring animations (think iOS sheet open/close), use a JavaScript spring physics library — Framer Motion, react-spring, GSAP — rather than fighting bezier curves to approximate spring damping. For frame-perfect sprite animations, use steps(). For purely linear progress (loading bars, unbounded spinners), linear is simpler and renders identically. For micro-interactions where the curve is barely noticed (under 200ms transitions), the default ease works fine — bezier customisation matters most for animations between 250ms and 1s.

    Frequently asked questions

    What’s the difference between cubic-bezier and ease keywords?

    The keywords (ease, ease-in, ease-out, ease-in-out, linear) are predefined cubic-bezier curves. cubic-bezier() lets you define any curve. The keywords cover 80% of cases; you reach for cubic-bezier() when you want a specific feel like Material Design’s standard curve or playful overshoot.

    Can the bezier handles go outside the 0–1 box?

    Y can — values above 1 produce overshoot; below 0 produce anticipation (the element moves backward briefly before going forward). X cannot — it must be between 0 and 1, since X represents time. The visual editor enforces this constraint.

    Should I use cubic-bezier for everything?

    No. Use ease-out for entering elements, ease-in for leaving, ease-in-out for symmetric motion, and reach for custom cubic-bezier() when you need a specific brand feel (Material, iOS) or expressive overshoot. Most apps standardise on 1–3 custom curves project-wide for consistency.

    What’s the new linear() function?

    CSS Easing 2’s linear() (Chrome 113+, Safari 17.2+) lets you describe a polyline of stops — useful for approximating spring physics or staged motion in a single CSS rule. It’s not a replacement for cubic-bezier() for typical UI transitions; it’s a new tool for complex timelines.

    Is my data uploaded?

    No. The generator runs in your browser. Your curve values, preview animation, and downloaded CSS stay on your device.

    Does cubic-bezier work on all browsers?

    Yes — universal support since Chrome 4 (2010), Firefox 4, Safari 4. It’s one of the safest CSS features. Even mobile browsers have stable rendering.

    Related tools and guides