Blog

  • 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

     

  • Tweet to Image Converter: Beautiful Framed Posts [2026]

    Tweet to Image Converter: Beautiful Framed Posts [2026]

    TL;DR: A tweet-to-image converter takes a tweet URL (or composes a fresh tweet) and renders it as a polished image — typically a tweet card on a gradient backdrop, ready to repost on Instagram, LinkedIn, or paste into a slide deck. Used for cross-platform sharing, social media presentations, blog hero images, and quote graphics. Our free tweet-to-image tool ships gradient backdrop presets, font customisation, and 4K export. Browser-only.

    Sharing a tweet outside X usually means a screenshot, but screenshots are inconsistent — different OS, different fonts, different aspect ratios, sometimes including unrelated UI. Designers solved this by rendering tweets as clean rectangular images on branded backdrops. Buffer, Hypefury, and dozens of indie tools popularised the format around 2020; by 2026 it’s standard for cross-platform content.

    Our tweet-to-image converter takes a tweet URL (we extract the text, author, avatar, timestamp, and engagement metrics via X’s oEmbed API) or lets you compose a tweet from scratch. Drop into a gradient backdrop, pick a font (X’s font is licensed; we use a similar open alternative), set padding, and export at 4K resolution. The output looks like a polished social-media graphic, not a phone screenshot. This guide explains the workflow, the legitimate-vs-deceptive line, and the gotchas with verified badges and quote tweets.

    Common use cases

    Use case Why image instead of share?
    Repost your tweet on Instagram IG doesn’t render X embeds; image is the standard
    Quote in a blog post / article Image is portable; embed depends on X being available
    Slide for a presentation Slide tools handle images; X embeds break offline
    LinkedIn post LinkedIn unfurls X URLs poorly; image gets more reach
    YouTube thumbnail Pull a great tweet into a thumbnail
    Newsletter feature Inline image is reliable; embeds depend on email client

    How to convert a tweet to an image

    1. Open the tweet-to-image converter
    2. Paste a tweet URL (we fetch text, author, timestamp via X’s oEmbed) or compose a tweet from scratch
    3. Pick a gradient backdrop preset, or upload your own background
    4. Adjust padding, corner radius, and font
    5. Toggle metadata: show / hide engagement counts, timestamp, verified badge
    6. Export PNG at 1×, 2×, or 4× — copy to clipboard or download

    Legitimate vs deceptive use

    Legitimate: Reposting your own tweets, quoting public statements with attribution, marketing creative for content marketing campaigns, slides for a presentation, blog hero images, podcast episode artwork.

    Don’t:

    • Compose a fake tweet “from” a real person and pass it off as authentic
    • Use the verified-checkmark badge on accounts that don’t have one
    • Modify a real tweet’s text and pretend the author posted that text
    • Generate “leaked” tweets as proof in disputes — defamation laws apply

    The output looks polished enough to fool a casual viewer at first glance. With “fake tweet of a real public figure” being a common misinformation pattern, treat the line carefully — when in doubt, attribute clearly that the image is a generated mockup, not a screenshot of the real platform.

    Common gotchas

    • X’s font is licensed. X (Twitter) uses Chirp font commissioned from Grilli Type — licensed for X use only. Our generator uses Inter as a similar open alternative. Visual parity is close but the typography purist will spot the difference.
    • oEmbed has rate limits. X’s oEmbed endpoint allows roughly 60 requests per minute per IP. Heavy use can hit limits; for batch processing, build the URL programmatically rather than scraping per-tweet.
    • Private tweets can’t be fetched. Tweets from protected accounts return errors. Public tweets work; private don’t.
    • Quote tweets and threads. oEmbed returns just the top-level tweet content. Quote tweets and full threads need separate handling — our generator includes a “thread mode” that fetches each reply tweet’s URL and stacks them.
    • The blue checkmark since 2023. X’s verification system changed in 2023 — paid verification (Twitter Blue) replaced legacy verification. Including a checkmark in your generator is fine for self-tweets where you have it; don’t add it to others’ tweets where the real account doesn’t display one.
    • Engagement counts go stale. The like/retweet/reply numbers in your generated image are the values at fetch time. If the tweet gets bigger, the image is “out of date”. For social-media content, that’s usually fine; for journalism, fetch fresh.

    When NOT to use this tool

    For tweets you’ll embed on a website where the real X embed is acceptable, use X’s official embed code — it loads live engagement counts and links back to the tweet. For deceptive content (fake tweets, manipulated text, fake verifications), don’t use this tool; use of the output for deception is fraud or defamation depending on context. For batch processing of many tweets, install twitter-api-v2 in Node and write a script — much faster than running the tool per-tweet. For animated tweet cards (typing effect, like-count animation), use a video tool like CapCut or After Effects.

    Frequently asked questions

    Does it fetch tweet text from a URL?

    Yes — paste the URL of a public tweet and we fetch text, author, avatar, timestamp via X’s oEmbed API. Private tweets and tweets from suspended accounts return errors.

    Can I compose a fake tweet?

    Yes — switch to “compose mode” and type the tweet from scratch with custom username, display name, and avatar. Use this for tutorials, mockups, and creative work where no real tweet exists. Don’t use it to fabricate a tweet “from” a real person and pass it off as real.

    What resolution does it export?

    Three options: 1× (1200×630, suitable for social), 2× (2400×1260, retina), or 4× (4800×2520, print). Pick based on where you’ll publish — for X reposts to Instagram, 2× is enough; for slide decks at 4K, use 4×.

    Are the gradient backdrops licensed?

    The gradient presets are designed by us, free to use commercially. The output image is yours — no attribution required.

    Is my data uploaded?

    To fetch tweet text from a URL we call X’s oEmbed API — the URL goes from your browser to X. The image rendering happens entirely in your browser; the final image is not uploaded.

    Can I customise the styling?

    Yes — gradient backdrop, font (Inter or system fonts), padding, corner radius, light/dark theme, with/without metadata. Save your style preset to reuse the same visual identity across multiple tweets.

    Related tools and guides

     

  • Instagram Filters in CSS: Clarendon, Gingham, More [2026]

    Instagram Filters in CSS: Clarendon, Gingham, More [2026]

    TL;DR: Instagram’s classic filters (Clarendon, Gingham, Moon, Lark, Reyes, Juno, etc.) can be approximated in CSS by stacking filter properties — contrast, saturate, hue-rotate, sepia — with carefully tuned values per filter. The output isn’t pixel-identical to Instagram’s proprietary algorithms, but it captures the look closely enough for previews, demo apps, and design mockups. Our free Instagram filters tool ships 30+ filter presets, applies them to any image in your browser, and copies the equivalent CSS.

    Instagram launched its filter library in 2010, popularising the now-iconic looks: Clarendon (cool, high-contrast), Gingham (vintage warm), Moon (dramatic black-and-white), Lark (high-saturation outdoor), Reyes (faded warmth), Juno (warm and saturated). Instagram’s actual implementations are proprietary GPU shaders. CSS approximations using filter functions get close to the look — close enough that web designers use them to mimic Instagram’s aesthetic in their own UIs.

    Our Instagram filters in CSS tool ships 30+ tested filter approximations. Drop an image, click a filter to preview, copy the CSS or export the filtered image as PNG. Useful for: feed-style mockups, photo galleries with consistent filter looks, hover effects that mimic Instagram, demo apps showing “before/after” filter comparisons. This guide explains how the CSS approximations work, where they fall short of Instagram’s real shaders, and the gotchas with hue-rotate.

    CSS approximations of classic filters

    Filter CSS approximation Aesthetic
    Clarendon contrast(120%) saturate(125%) High-contrast cool tones
    Gingham contrast(90%) brightness(105%) sepia(8%) Faded vintage warmth
    Moon grayscale(100%) contrast(110%) brightness(110%) Dramatic B&W
    Lark contrast(95%) saturate(110%) brightness(110%) Outdoor / nature
    Reyes sepia(22%) brightness(110%) contrast(85%) saturate(75%) Faded warm
    Juno saturate(130%) contrast(105%) hue-rotate(-10deg) Warm + saturated
    Walden brightness(110%) hue-rotate(-10deg) sepia(30%) saturate(160%) Bright yellow-tint
    1977 contrast(110%) brightness(110%) saturate(130%) sepia(50%) Faded film, retro

    Why CSS approximations aren’t exact

    Instagram’s filters are GPU shaders that operate per-pixel with custom curves, masks, and blend modes. CSS filter functions (contrast, saturate, hue-rotate, sepia) are simpler linear or per-channel transforms. The differences:

    • Tone curves: Instagram applies S-curves and custom tone-mapping that CSS can’t do directly. Our approximations use linear contrast/brightness, which gets close but not pixel-identical.
    • Per-channel adjustments: Real filters often boost reds and dampen blues separately. CSS can do hue-rotate (rotate all hues equally) but not selective per-color editing.
    • Lookup tables (LUTs): Many real filters use 3D LUTs to map every input color to an output color. CSS has no equivalent.
    • Blend modes: Instagram filters layer on tints with screen / multiply / overlay blend modes. CSS supports mix-blend-mode but only on stacked elements, not on the image itself directly.

    For a 95% accurate match in the browser, our approximations are the practical limit. For pixel-exact reproduction, use a dedicated image-processing library (Pixi.js, GLFX) with custom GLSL shaders.

    How to apply Instagram-style filters

    1. Open the Instagram filters tool
    2. Drop an image (or use one of the demo photos)
    3. Click any filter preset to preview live
    4. Adjust strength slider (0–150% — higher than 100% over-applies the effect)
    5. Click Export to bake the filter into a PNG/JPG, or Copy CSS for the equivalent filter declaration

    Common gotchas

    • The Instagram filter trademarks belong to Meta. Filter names like “Clarendon”, “Gingham”, “Moon” are Meta trademarks. Using them in your own product to label CSS approximations is legally grey — for commercial work, use generic names (“Cool”, “Vintage”, “B&W”) to avoid confusion. Our generator labels them with the recognisable names for educational reference.
    • Filters change Instagram’s CSS implementations evolve. Instagram has updated filter algorithms several times. Approximations that matched the look in 2018 may not match the 2026 version exactly.
    • Hue-rotate is unintuitive. Rotating hue by 10° shifts blue toward purple, but the same 10° from yellow lands in green. Test with the actual image — don’t pick angles by intuition.
    • Filters compound badly. Stacking 3+ filters at full strength produces over-processed output. Real Instagram filters are designed as single composites. Keep filter stacks short and adjust strength globally.
    • JPEG compression after filtering. Heavy filters (high contrast, high saturation) push pixels into JPEG’s compression-friendly bands, then JPEG compression can’t capture the subtleties. For high-quality output, export PNG and convert to JPEG only at the final step.
    • CSS filter is render-time, not destructive. Applied via CSS filter: declaration, the original image stays unchanged in the DOM. Apply via canvas (the export path) when you want a permanent change.

    When NOT to use CSS Instagram filters

    For pixel-exact recreation of Instagram’s filters (e.g., for a competitive analysis), you need either Instagram itself or a dedicated GLSL implementation — CSS can’t reach that fidelity. For commercial product features (“apply Instagram filter to your photo”), use proper trademark-friendly names and don’t mention “Instagram” in your UI without licensing. For batch image processing in CI, use sharp + custom transforms in Node — much faster than running through a browser tool. For animated filter transitions (smoothly cross-fading between filters), use CSS transitions on the filter property — works but limited to functions CSS supports.

    Frequently asked questions

    Are these the actual Instagram filters?

    No — they’re CSS approximations. Instagram’s real filters are proprietary GPU shaders. Our CSS combines contrast, saturate, hue-rotate, sepia, etc. to match the look. Visually similar; not pixel-identical.

    Can I use the filter names commercially?

    “Clarendon”, “Gingham”, “Moon” etc. are Meta trademarks. For commercial products labelling filter options, use generic names (“Cool”, “Vintage”) to avoid trademark issues. The CSS techniques themselves are open and free to use.

    Does it support PNG transparency?

    Yes — PNG alpha channels survive every filter. Drop-shadow specifically uses the alpha channel for the silhouette. JPEG inputs don’t have alpha; the rectangular bounding box shows in any drop-shadow.

    Can I apply filters in CSS without baking them in?

    Yes — that’s the use case for the “Copy CSS” option. Apply via img { filter: contrast(120%) saturate(125%); } in your stylesheet, and the original image stays untouched. Use baking (PNG export) when you want the filter permanent.

    Is my image uploaded?

    No. Filters apply via canvas in your browser. The image is loaded into a blob URL and processed locally.

    Can I create a custom filter?

    Yes — use the “Custom” mode and adjust each CSS filter function manually with sliders. Save your settings as a named preset. Useful for matching a brand-specific look across many images.

    Related tools and guides

     

  • Average Color of an Image: Finder Tool [2026]

    Average Color of an Image: Finder Tool [2026]

    TL;DR: An image average color finder computes the single colour that best represents an image — usually the arithmetic mean of every pixel’s RGB values. The mean often produces a muddy gray for colourful images; the dominant colour (most-frequent cluster) is usually more useful. Used for hero gradients that match a photo, fallback colours while a lazy-loaded image loads, theme-detection from album art, and accessibility checks. Our free image average color finder reports mean, median, and dominant in one go.

    “What’s the average colour of this image?” is a deceptively simple question. The naive answer — sum every pixel’s red, green, and blue values, divide by total pixels — produces the mean colour, but that’s often a muddy brown that doesn’t match anyone’s intuition of what the image “looks like”. A bright photo of a sunset (oranges, reds, dark blues) averages to a dull purple-grey. The dominant colour — the colour that appears most frequently after clustering — is usually a more useful answer.

    Our image average color finder reports four different metrics at once: mean (arithmetic average), median (the colour at the centre of the distribution), dominant (most common after clustering), and weighted average (excluding background pixels). Pick the one that matches your need. Drop in any image, get all four values as HEX/RGB/HSL/OKLCH, plus a CSS-variable export. Browser-only.

    Mean vs median vs dominant — pick the right metric

    Metric How it’s computed Best for
    Mean Sum each channel, divide by pixel count Lazy-load placeholders (BlurHash equivalent)
    Median Value at the 50th percentile per channel Robust against outlier pixels
    Dominant Most common cluster after K-means k=1 Theme detection, brand-color extraction
    Weighted Mean excluding near-white / near-black Photos with white background; ignores chrome
    Center-weighted Mean with central pixels weighted higher Subject-focused content (portraits, product shots)

    Why mean often disappoints

    Imagine an image of a sunset: red sun, orange sky, blue water. The mean of red + orange + blue is a desaturated brown-grey — a colour that nothing in the image actually is. Mean is a statistical average, not a perceptual representative. For lazy-load placeholders this is fine (you want a single colour that’s unobtrusive), but for “what colour is this image?” answers, dominant is usually closer to intuition.

    Mean works well for:

    • Image-loading placeholders (Material Design’s blur-up technique)
    • Fallback background colour while lazy-loading
    • Generating a complementary text-overlay colour

    Dominant works better for:

    • Theme detection — pick a UI accent colour matching a hero photo
    • Brand-colour extraction from a logo
    • Generating gradient backgrounds that “match” the image

    How to find the average color

    1. Open the average color finder
    2. Drop your image (JPG, PNG, WebP, HEIC supported)
    3. The tool computes mean, median, dominant, weighted average — all four — in 1–2 seconds
    4. Pick the metric that fits your use case; copy HEX, RGB, HSL, or OKLCH
    5. Export as CSS variable (--image-color: #94896D) for direct use in stylesheets

    Common gotchas

    • Transparent pixels affect mean. By default we count fully-transparent pixels as the chosen “background” colour (white by default). Toggle “ignore alpha” to skip them entirely — better for logos on transparent backgrounds.
    • Resolution affects performance. Computing mean is O(n) over pixel count. A 4000×3000 image (12M pixels) processes in ~200ms; a 12000×9000 image (108M pixels) takes ~2 seconds. The tool downsamples to 1024×1024 internally for speed — visually identical result for any image larger than that.
    • JPEG compression artefacts shift the mean. Heavily compressed JPGs introduce per-block colour shifts that pull the mean toward greys. For brand-color work, use original PNG / TIFF / WebP if available.
    • EXIF rotation matters. A photo from a phone may be stored sideways with EXIF rotation metadata. Our tool reads the EXIF orientation and applies it before computing — ensures the “mean” is over the visible image, not a sideways version.
    • Per-region sampling for hero images. A hero image often has chrome at the top (logo, navigation) that you don’t want included in the average. Use the “region” tool to draw a rectangle covering only the photographic content, then compute over that.
    • Color space matters. Mean in RGB space biases toward greys (perceptually inaccurate). Mean in OKLab space produces a more perceptually-uniform answer. Our tool reports both — pick OKLab for design work, RGB for compatibility.

    When NOT to use this tool

    For a multi-colour palette extracted from an image, use the Image Color Extractor — it returns 2–12 colours via K-means clustering. For pixel-perfect colour sampling at a single point, use the Image Color Picker — it shows the exact colour under your cursor. For lazy-load placeholders in production, libraries like plaiceholder or blurhash are more efficient than recomputing on every page load. For colour-detection in real-time video, use OpenCV.js or a WebGPU shader — much faster than per-frame canvas sampling.

    Frequently asked questions

    Why does the mean colour look different from the image?

    Mean is a statistical average across all pixels. For images with high colour variation (sunsets, landscapes), the mean often lands in muddy territory — desaturated brown or grey — because opposing colours cancel out. The dominant colour is usually closer to what you’d intuitively call “the image’s colour”.

    Mean, median, or dominant — which should I use?

    For lazy-load placeholders: mean (unobtrusive). For theme detection or brand-colour extraction: dominant. For photos with extreme outliers (one bright spot in a dark image): median. Try all four — our tool computes them simultaneously and shows all swatches.

    Does it support transparent backgrounds?

    Yes — toggle “ignore alpha” to skip transparent pixels entirely. Otherwise transparent pixels are blended against your chosen background colour (white by default). Critical for logos on transparent backgrounds.

    Can I sample a specific region?

    Yes — draw a rectangle on the image to limit the sample area. Useful for hero images where you want to skip the navigation chrome, or product photos where you want to skip the white background.

    Is my image uploaded?

    No. The finder runs in your browser via the canvas API. Image data is processed locally — never sent to our servers.

    What’s the difference between OKLab and RGB averaging?

    Averaging in RGB biases toward greys because R+G+B sums tend to centre around perceptual middle. Averaging in OKLab (a perceptually-uniform colour space) produces a result closer to what the eye perceives as the “centre” of the image’s colour distribution. Our tool reports both for comparison.

    Related tools and guides

     

  • SVG Stroke to Fill Converter: Outline-to-Path [2026]

    SVG Stroke to Fill Converter: Outline-to-Path [2026]

    TL;DR: An SVG stroke-to-fill converter takes paths drawn with stroke="..." + stroke-width="N" and replaces them with filled outline paths that produce identical visual rendering — but as filled regions, not strokes. Necessary for laser cutters, CNC routers, vinyl plotters, embroidery machines, and any pipeline that scales SVGs without honouring stroke-width. Our free SVG stroke-to-fill tool uses the same path-offset algorithms as Inkscape and Illustrator’s “Stroke to Path” command.

    SVG paths can be rendered two ways: with a stroke (a line drawn along the path with a configurable width) or as a fill (the area enclosed by the path is filled with colour). Visually they can look identical — a 4px black stroke around a circle and a filled donut shape with the same dimensions render the same. But many pipelines that consume SVG ignore stroke entirely:

    • Laser cutters (Glowforge, Epilog, AxiDraw): cut along path centerlines, but interpret fill as engraving area. A stroked path may be cut as the path itself with no width.
    • CNC routers (vCarve, Carbide Create): treat stroke-width as visual decoration, not toolpath geometry.
    • Vinyl plotters (Cricut, Silhouette): cut along paths; stroke-width has no effect on the cut.
    • Embroidery digitisers: convert paths to stitches; strokes need explicit fill geometry.
    • Some printers and PDF generators: round stroke-width to nearest pixel multiple at low DPI.

    The fix: convert every stroke to a filled outline path before exporting. Our SVG stroke-to-fill converter does this automatically — paste your SVG, get back a version where every stroked path has been replaced with an equivalent filled outline. The visual rendering is unchanged in browsers but the geometry is now portable across every SVG-consuming pipeline.

    When you need stroke-to-fill conversion

    Pipeline Honours stroke-width? Action
    Web browser rendering Yes No conversion needed
    Print PDF Mostly Convert if printing under 100 DPI
    Laser cutter (Glowforge, Epilog) No Convert before export
    CNC router (Shapeoko, Carbide) No Convert before export
    Vinyl plotter (Cricut) No Convert before export
    Embroidery (PE-Design) No Convert before export
    Figma / Illustrator export Yes No conversion needed

    How the conversion works

    The technique is path offsetting. For a path defined by a series of points, the offset path is a new path running parallel to the original at a constant distance (half the stroke-width) on each side. The two offset paths plus the rounded line caps form a closed outline — a filled region equivalent to the stroked line.

    Edge cases that need careful handling:

    • Line caps: butt, round, square. Each requires different geometry at the path endpoints.
    • Line joins: miter, round, bevel. Where path segments meet, the corners need different treatments.
    • Self-intersections: a path that crosses itself produces overlapping offset regions that need union-ing.
    • Bezier curves: the offset of a Bezier isn’t itself a Bezier — it’s approximated with multiple Bezier segments.

    Most converters (including ours) use the Clipper library or paper.js’s PathOffset algorithm — the same code Inkscape’s “Stroke to Path” command runs.

    How to convert SVG strokes to fills

    1. Open the SVG stroke-to-fill converter
    2. Paste your SVG markup or upload an .svg file
    3. The tool detects every stroked path and converts each to a filled outline
    4. Preview shows before/after side by side — should look visually identical
    5. Click Download for the converted SVG

    Common gotchas

    • Output is bigger. A filled-outline path has more points than the stroked version. File size typically grows 30–80%. For laser/CNC export this is fine; for web rendering, keep the stroked version.
    • Anti-aliasing differs slightly. Browsers anti-alias strokes differently from filled paths. Visual difference is usually invisible but exists at the pixel level — zoom to 400% and you may see edge differences.
    • Doesn’t simplify nested groups. If your SVG has nested <g> groups with transforms, the conversion preserves the structure. Some legacy laser-cutter software trips on nested groups; flatten with a separate pass if needed.
    • Stroke-dasharray becomes dashed filled paths. Dashed strokes (stroke-dasharray) convert to multiple separate filled segments. Visual is correct but the path count multiplies.
    • Round caps and joins add curve segments. A path with stroke-linecap="round" gets quarter-circle Bezier curves at endpoints in the output. Visual unchanged; geometry slightly more complex.
    • Variable stroke widths aren’t standard SVG. If you’ve used a non-standard stroke-width-variable extension (Illustrator’s variable-width strokes), the tool can’t reproduce that — it treats stroke-width as constant per path.

    When NOT to use this tool

    If your destination consumes SVG with full stroke support (modern browsers, Adobe Illustrator, Figma, Affinity), don’t convert — it bloats the file with no benefit. For web SVG, stroke-width is rendered correctly everywhere. For interactive SVG (paths animated with stroke-dasharray for “drawing” effects), don’t convert — you’ll lose the ability to animate the stroke offset. For SVGs you’ll edit later in a vector tool, keep strokes — they’re easier to manipulate than filled outlines. Use this tool only when exporting to a destination that ignores stroke-width.

    Frequently asked questions

    Why do I need to convert strokes for laser cutters?

    Laser cutters cut along path geometry, not stroke decoration. A 4mm-wide stroked line in your design isn’t a 4mm-wide cut — the cutter follows the centerline of the path. To produce a 4mm-wide cut region, the geometry must be a filled 4mm-wide outline shape. Conversion makes the geometry match what the cutter sees.

    Will the output look the same in a browser?

    Yes — visually identical at typical viewing zoom. Browsers anti-alias strokes and fills slightly differently, so at 400%+ zoom you might see edge differences, but the rendered effect is the same.

    Does it support all SVG features?

    Most: line caps (butt, round, square), line joins (miter, round, bevel), dashed strokes, miter limits, transforms. It doesn’t handle: variable-width strokes (Illustrator extension), stroke alignment (Inkscape’s stroke-alignment=”inset/outset”), or pattern-based strokes. Those convert with imperfect approximations.

    What’s the file-size penalty?

    Typically 30–80% larger output. A 12 KB SVG with strokes becomes 18–22 KB after conversion. The growth comes from filled outlines having more path points than centerline strokes, especially with rounded line caps.

    Is my SVG uploaded?

    No. The converter runs in your browser. SVG markup is processed locally — never sent to our servers.

    Can I batch-convert many SVGs?

    For one or two files, this tool is fastest. For batch processing (50+ files), use Inkscape’s command line: inkscape --export-type=svg --export-text-to-path --export-area-page --export-stroke-to-path *.svg. Same algorithm, scriptable.

    Related tools and guides