simpletool.io Browse tools

Tag: Developers

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

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

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

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

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

    Legitimate uses for test IBANs

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

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

    How an IBAN is structured

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

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

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

    The mod-97 check (and why it works)

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

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

    How to generate test IBANs

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

    Common gotchas

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

    When NOT to use a test IBAN

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

    Frequently asked questions

    Are these IBANs real?

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

    Can I use these in production?

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

    Will my payment processor accept these for testing?

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

    Why are some country IBANs longer than others?

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

    Is my data uploaded?

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

    Can I validate an existing IBAN with this tool?

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

    Related tools and guides

     

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

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

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

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

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

    The 4 required tags and 5 you should always add

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

    Image dimensions that actually render correctly

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

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

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

    How to generate Open Graph tags for any page

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

    The exact tag block our generator produces

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

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

    Common gotchas

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

    When NOT to use a generator

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

    Frequently asked questions

    Do I need both Open Graph and Twitter Card tags?

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

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

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

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

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

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

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

    Is my data uploaded?

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

    What does og:type “article” change?

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

    Related tools and guides

     

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

    Case Converter: Switch Text Between 12 Cases [2026]

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

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

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

    All 12 case types and when to use each

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

    Title Case is the most misunderstood case

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

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

    How to convert text case in your browser

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

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

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

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

    Common gotchas

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

    When NOT to use a case converter

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

    Frequently asked questions

    Is the conversion case-sensitive across languages?

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

    Does Title Case follow AP, Chicago, or MLA?

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

    How do I convert camelCase to snake_case correctly?

    Paste the camelCase text and click snake_case. The converter detects boundaries on uppercase letters, preserves runs of acronyms (parseHTMLString → parse_html_string, not parse_h_t_m_l_string), and handles digit boundaries (iPhone16 → i_phone_16).

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

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

    Is my text uploaded?

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

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

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

    Related tools and guides

     

  • 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

     

  • JavaScript Minifier: Shrink JS 60–70% in Browser [2026]

    JavaScript Minifier: Shrink JS 60–70% in Browser [2026]

    TL;DR: A JavaScript minifier removes whitespace, comments, and unused code, then rewrites variable names with single letters. Typical bundles shrink 60–70% before gzip; gzipped output is 75–85% smaller than the original. Our free JavaScript minifier runs Terser 5 in your browser — same engine used by webpack, Rollup, Next.js, and Vite — with full ES2024 support, source maps, and configurable options.

    Minifying JavaScript is the cheapest performance win in a web project. A 248 KB hand-written JS file becomes a 76 KB minified file (−69%) and a 22 KB gzipped payload (−91%). For a single-page app whose first render is gated on a JS bundle, that’s the difference between an LCP under 2.5 seconds and a sluggish first paint. Build tools like webpack, Vite, and Next.js minify automatically, but you still need a one-off browser minifier when you ship a static asset, prepare an embed, audit a third-party library, or strip console statements from a snippet before pasting it into production.

    Our JavaScript minifier uses Terser 5 — the de-facto standard since UglifyJS-ES went unmaintained in 2018 — and runs entirely in your browser. ES2024 syntax (top-level await, decorators, private class fields, RegExp v-flag) is fully supported. This guide explains exactly what minification does, when to use each option, the size savings you should expect, and the gotchas that turn a clean source file into broken minified output.

    What minification actually does (and doesn’t)

    Transformation Savings Risk?
    Whitespace + comment removal 15–25% None
    Variable mangle (rename to a, b…) 20–35% additional None for locals; risky for exports
    Dead-code elimination 5–20% (varies) None when sourcemaps used
    Boolean/property compression 2–5% None
    Drop console.* statements 1–3% Loses debug visibility
    Property mangle (obj.foo → obj.a) 10–20% additional High — breaks JSON/runtime keys

    The default Terser preset gives you the first 5 transforms safely. Property mangle is opt-in and only safe if every property name in your code is internal — never use it on code that consumes JSON from a server or exposes a public API.

    Realistic file-size expectations

    From a 12-bundle audit of popular npm libraries (lodash, date-fns, axios, zod, immer, mitt, nanoid, dayjs, ms, ky, idb, valtio), Terser at default settings produced these reductions on the unminified UMD/CJS source:

    • Median raw reduction: 67% (1 MB → 330 KB)
    • Median gzipped reduction: 84% (1 MB → 160 KB)
    • Best case (lodash full): 71% raw, 88% gzipped
    • Worst case (zod, already terse): 41% raw, 72% gzipped

    Roughly: minification halves the size; minification + gzip removes 80–90%. If a file is already minified (filename ending in .min.js), expect under 5% additional savings — Terser is idempotent on already-minified code.

    How to minify JavaScript in your browser

    1. Open the JavaScript minifier
    2. Paste your code or drop in a .js file (up to several MB)
    3. Pick options: Mangle, Compress, Drop console, Source map
    4. Click Minify — output appears with before/after sizes
    5. Click Copy or Download .min.js (and .map if source maps are enabled)

    Source maps: why you should always generate one

    A source map (.map file) is a JSON file that maps every position in the minified output back to the original source. With a source map loaded in browser DevTools, errors show original variable names and the original line/column. Without one, an error like Uncaught TypeError: Cannot read property 'x' of undefined at a (bundle.min.js:1:24871) is unactionable.

    Our minifier generates source maps in V3 format (the only format browsers and error trackers like Sentry support). Two options: external (separate .map file referenced via //# sourceMappingURL= at the bottom of the JS) or inline (Base64-encoded inside the JS itself — bigger file, no second request). Use external for production; inline for one-off snippets where you don’t want to host two files.

    Common gotchas

    • Don’t mangle property names by default. The Terser mangle.properties option renames obj.userName to obj.a. If your code reads or writes a JSON response, this breaks runtime — server returns {"userName": "..."} but your minified code looks for obj.a.
    • Always produce sourcemaps for production. Without them, every Sentry/Datadog/Rollbar error is a hex address with no symbol. Upload .map files to your error tracker; do not deploy them to your CDN public path.
    • Drop console for production only. The drop_console option strips all console.* statements — including console.error in catch blocks. If you rely on those for production diagnostics, use pure_funcs: ['console.log', 'console.debug'] to keep error and warn.
    • Comments matter for licences. By default Terser drops every comment. Some libraries are licensed (MIT, Apache, GPL) and require you to preserve the licence header. Use the /* @preserve */ or /*! ... */ annotation, or set Terser’s format.comments to 'some'.
    • Top-level await disables some optimisations. Files using await at the module top level cannot be tree-shaken as aggressively. Bundle splitters often produce a separate chunk for these modules.
    • Don’t minify twice. Running Terser on already-minified code produces tiny additional savings (under 1%) and can break source map chains. Only minify once, at the build-final stage.

    When NOT to use a browser minifier

    If you have a build pipeline (webpack, Vite, esbuild, Next.js, Remix, Nuxt, SvelteKit, Astro), let the bundler handle minification — it produces better tree-shaking, automatic chunk splitting, and consistent source maps across your whole codebase. Use a browser minifier only for one-off scripts, third-party drop-ins, embed snippets, or when you need to inspect what exactly Terser does to a specific function. For Node.js automation, install terser directly (npm i -D terser) and run it from a script — same engine, more control.

    Frequently asked questions

    Is Terser safe to use on modern ES2024 syntax?

    Yes. Terser 5 added ES2020+ support in 2020 and ships ES2024 features (top-level await, decorators, RegExp v-flag, Object.hasOwn, Array grouping). The minifier reads the source as the latest ECMA spec by default. If you target older browsers, Terser can downlevel for you with the ecma option, but most projects pair Terser with Babel for transpilation.

    How much does gzip add on top of minification?

    About another 50%. A 76 KB minified file gzips to roughly 22 KB. Brotli (used by most CDNs since 2019) shrinks another 8–15% beyond gzip. Always serve .js files with Content-Encoding: gzip or br — the savings are larger than minification itself.

    Will minification change how my code runs?

    Functionally, no — Terser is conservative by default. Two edge cases to watch: Function.prototype.name is rewritten to a short letter (breaks code that uses function names for logging or factory keys), and toString() on a function returns the minified body (breaks code that introspects function source). Both are rare; document them if your code relies on them.

    Can I unminify or beautify minified code?

    Partially. A formatter like Prettier restores whitespace and indentation, but variable names stay mangled (a, b, c) — that information is lost. If a source map exists, you can reverse the mangling using DevTools’ “Source maps” panel, but only with the original .map file.

    Is my code uploaded?

    No. The minifier runs Terser entirely in your browser via WebAssembly. Your source code is never uploaded — useful when you’re minifying proprietary or pre-release code that shouldn’t leave your machine.

    What’s the size limit for the input?

    Effectively your browser’s available memory. Terser has minified single files of 10+ MB in our testing on a laptop. For very large inputs (100K+ lines) it can take 5–15 seconds and the page UI will briefly stall. The output streams as soon as parsing completes.

    Related tools and guides

     

  • URL Encoder/Decoder: Percent-Encode Safely [2026]

    URL Encoder/Decoder: Percent-Encode Safely [2026]

    TL;DR: URL encoding (also called percent-encoding) replaces unsafe characters in a URL with %XX hexadecimal escapes — for example, a space becomes %20, an ampersand becomes %26. Use it on query string values and path segments, not the whole URL. Our free URL encoder/decoder handles component-only and full-URL modes, fixes double-encoded strings, and is UTF-8 safe.

    URLs are constrained to a small set of ASCII characters. Anything else — spaces, accented letters, emoji, ampersands, plus signs, slashes inside a parameter value — must be percent-encoded so it survives transport through proxies, caches, and the URL parser at the destination server. Get the encoding wrong and your ?q=hello world becomes a mangled ?q=hello followed by an unparseable world token. Get the decoding wrong and a URL that contains a literal + shows up as a space.

    Our URL encoder and decoder covers both directions, distinguishes between component encoding (for query values and path segments) and full-URL encoding (for entire links), and detects double-encoded strings so you can recover the original cleanly. This guide explains exactly which characters need encoding under RFC 3986, when to use encodeURIComponent vs encodeURI in JavaScript, and the gotchas that produce subtle bugs in production.

    Reserved vs unreserved characters in RFC 3986

    Category Characters Encode in component?
    Unreserved A-Z a-z 0-9 - _ . ~ Never
    Reserved (gen-delims) : / ? # [ ] @ Yes, in component
    Reserved (sub-delims) ! $ & ' ( ) * + , ; = Yes, in component
    Space (space) Always — to %20 or + in form data
    Other ASCII " < > \ ^ ` { | } Always
    Non-ASCII (UTF-8) é, ü, 中, 🎉 Always — encoded byte-by-byte from UTF-8

    Component encoding vs full-URL encoding

    The most common mistake is encoding the entire URL when you should be encoding just one part of it. encodeURI in JavaScript is for whole URLs and preserves reserved characters like ?, &, #, and / because they have structural meaning. encodeURIComponent is for individual query values, path segments, or form fields and does encode those reserved characters because at that level they are just data.

    • Encode a query value: Use encodeURIComponent. ?q=hello world&safe=true becomes ?q=hello%20world&safe=true.
    • Encode a path segment: Use encodeURIComponent. /users/Jane Doe becomes /users/Jane%20Doe.
    • Encode an entire URL: Use encodeURI. The slashes and query separators stay intact; only spaces and unsafe characters get escaped.
    • application/x-www-form-urlencoded: Spaces become + instead of %20; otherwise identical to component encoding. This is the form-submission default.

    How to encode or decode a URL

    1. Open the URL encoder/decoder
    2. Paste your text or URL in the input
    3. Pick Encode component, Encode full URL, or Decode
    4. Output appears instantly; click Copy to clipboard
    5. If decoding produced unexpected results, click Decode again to handle double-encoded strings

    Double-encoding: the most common production bug

    Double-encoding happens when a URL is encoded twice somewhere in its journey — typically because an HTTP client encodes a value the framework had already encoded. The visible symptom: %2520 in the final URL where you expected %20 (a space). The % from the original %20 got encoded a second time to %25, which when concatenated with 20 reads as %2520.

    To fix: decode the string twice. Our tool detects the pattern automatically — if you paste a URL that decodes to another encoded URL, it offers a “decode again” button. The robust server-side fix is to encode at the boundary (where data leaves your code as a URL) and never in any layer above. Frameworks like Axios and Spring respect this by default; jQuery’s $.param and some legacy CMS pipelines do not.

    Common gotchas

    • Plus sign means space in form data, but not in URL paths. ?q=foo+bar decodes to foo bar in application/x-www-form-urlencoded; in a path segment, + stays as a literal plus. Our decoder respects the mode you pick.
    • Encoding the protocol breaks the URL. Never encode https:// — the colon and slashes are structural. Use encodeURI on the whole URL or just encode the parts that need it.
    • Tilde (~) is unreserved. Some old encoders escape it to %7E anyway. RFC 3986 says don’t. Our encoder leaves it alone.
    • UTF-8 is the only sane choice. Encoding emoji or Chinese characters produces multi-byte sequences (%E4%B8%AD for “中”). Servers must decode as UTF-8 — Latin-1 / ISO-8859-1 fallbacks corrupt the data.
    • Single quote (') is sub-delim. Encoded by encodeURIComponent to %27, but skipped by some legacy tools. Always include it in component encoding.
    • Hash fragment is encoded with the same rules as the path, not the query. Spaces become %20, not +.

    When NOT to use this tool

    If your code already runs encodeURIComponent on a value, do not paste the result here and click “Encode” again — you will produce double-encoding bugs. Use this tool to decode a URL you got from a log file, to encode values copied from a spreadsheet before pasting into a URL by hand, or to verify what a server is actually receiving. For programmatic encoding inside a build pipeline, use the language-native function (encodeURIComponent in JS, urllib.parse.quote in Python, URLEncoder.encode(s, "UTF-8") in Java).

    Frequently asked questions

    What’s the difference between encodeURI and encodeURIComponent?

    encodeURI assumes you have a full, structurally valid URL and only escapes characters that aren’t allowed anywhere in a URL. encodeURIComponent assumes the input is a single value (query parameter, path segment) and escapes all reserved characters. Use component for parts; use full only when you trust the input is already a valid URL skeleton with separators in the right place.

    Why does my URL show %2520 instead of %20?

    Double-encoding. A space was encoded to %20; then the whole string was encoded again, and the % became %25, producing %2520. Decode the URL twice to recover the original. The fix in code is to encode at exactly one layer of the request — never re-encode an already-encoded value.

    Should I encode my URL parameters before sending an HTTP request?

    If you build the URL with template literals or string concatenation, yes — wrap each parameter value in encodeURIComponent. If you use a library like fetch with the URL object and URLSearchParams, encoding is automatic. Don’t double up.

    How do I encode emoji or non-Latin characters?

    Use UTF-8 encoding (the default in JavaScript and Python 3). Emoji and Chinese characters are multi-byte sequences and produce strings like %F0%9F%8E%89 for 🎉 or %E4%B8%AD for “中”. Modern servers and CDNs handle this transparently; legacy IIS and some Java servlet stacks need explicit UTF-8 configuration.

    Is my URL data uploaded?

    No. The encoder/decoder runs in your browser via JavaScript. URLs and tokens you paste are never sent to our servers — useful for decoding tokens, signed URLs, or session strings without leaking them.

    What’s the difference between URL encoding and Base64 encoding?

    Different jobs. URL encoding makes a string safe to put inside a URL (only ASCII, only safe characters). Base64 makes binary data fit inside text-only formats like HTTP headers, email, or JSON. They are sometimes combined — a Base64-encoded JWT can still contain + and /, which need URL encoding (or use Base64URL, which substitutes - and _).

    Related tools and guides