simpletool.io Browse tools

Tag: Productivity

  • 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

     

  • Split PDF Online: Browser-Only, 100% Private [2026]

    Split PDF Online: Browser-Only, 100% Private [2026]

    TL;DR: Splitting a PDF means producing one or more smaller PDFs from a larger one — by page range (pages 1–10), every page (one file per page), every N pages, or by extracting specific page numbers. Our free PDF splitter runs pdf-lib entirely in your browser. Files never upload — important when splitting contracts, payslips, medical records, or anything you wouldn’t paste into a free upload-to-server tool.

    Splitting a PDF is the kind of task that feels small until you need to do it with a sensitive file. The default workflow — Google “split pdf” → upload to ilovepdf or smallpdf — sends your contract, salary sheet, or hospital record through a stranger’s server, where it sits in their cache for hours. For the same task, browser-only tools using pdf-lib (the JavaScript library that powers most modern PDF utilities) do the work locally with no data leaving your machine.

    Our PDF splitter handles the four common modes — page range, every page, every N pages, extract specific pages — with drag-and-drop input and one-click ZIP download for multi-file outputs. This guide explains exactly what each mode does, the technical limits, the privacy difference between browser and server splitters, and the gotchas with bookmarks and form fields.

    The 4 split modes — and which one you actually want

    Mode Output Best for
    Page range 1 file containing pages X–Y Extracting a chapter or section
    Per page N files, one page each Multi-page invoices, scanned receipts
    Every N pages ⌈N/k⌉ files of k pages each Splitting a long report into chapters
    Extract pages 1 file containing only the listed pages Pulling specific pages out of a deck
    Multi-range Multiple files, one per range Splitting a combined PDF into sections

    Privacy: browser-only vs server-based splitters

    Most “free PDF splitter” sites upload your file to their server, run the split there, and let you download the output. That means: your file sits in their cache for some retention period (often 24 hours, sometimes longer); their backups potentially preserve it; their privacy policy controls what happens to it. For a marketing brochure that’s fine. For a contract, payslip, medical record, signed legal document, or anything you’d email with care — it’s not.

    Our PDF splitter uses pdf-lib, a JavaScript library that runs entirely in the browser. When you drop a file in, the bytes never leave your tab. You can verify this in your browser’s Network tab — the file selection triggers zero outbound requests. The split files appear in your browser’s download folder via a local blob URL, not a server response.

    How to split a PDF in your browser

    1. Open the PDF splitter
    2. Drop your PDF into the upload zone, or click to pick a file
    3. Pick the split mode: Range, Per page, Every N pages, Extract, or Multi-range
    4. Type the page numbers (1-5, 8, 12-20 for multi-range)
    5. Click Split — output files appear immediately
    6. Click Download all (ZIP) for multi-file output, or download each file individually

    Technical limits and what to expect

    pdf-lib runs in WebAssembly and is fast for moderate-size PDFs:

    • Up to ~100 pages, mixed text and images: instant (under 1 second)
    • 100–500 pages with embedded fonts: 2–10 seconds
    • 500–1000 pages, scanned image-heavy: 10–60 seconds, may briefly stall the page
    • 1000+ pages or files over 200 MB: at the edge of browser memory; consider splitting in batches
    • Encrypted (password-protected) PDFs: require the password before splitting; pdf-lib supports both user and owner password

    Memory is the real limit. Mobile browsers are more restrictive than desktop — a 200 MB PDF that splits cleanly on a laptop may crash an iPhone Safari tab. For very large files, use the desktop browser or split in two stages.

    Common gotchas

    • Bookmarks and outlines. When you split a PDF, bookmarks pointing to extracted pages are preserved; bookmarks pointing to pages outside the new file are dropped. This is the correct behaviour but surprises people who expect the entire outline to follow.
    • Form fields. Interactive form fields (signature blocks, checkboxes, text inputs) on extracted pages keep their values. Fields on dropped pages are removed. Form-level metadata (default values, validation rules) is preserved at the document level.
    • Annotations and highlights. Comments, highlights, and stamps on extracted pages move with them. Annotations referencing dropped pages may show a broken link icon.
    • Linked TOCs break. A table of contents with hyperlinks to specific pages becomes partially broken when you split — half the links point to non-existent pages. Either remove the TOC or split before generating the TOC.
    • Output file names. Default naming is filename-part-N.pdf. Customise with the “Filename pattern” input — {name}-{from}-{to}.pdf tokens are supported.
    • Compression isn’t preserved by default. pdf-lib re-streams content; deeply-compressed input PDFs may grow ~5% in the output. To keep size down, run the output through a PDF compressor after splitting.

    When NOT to use this tool

    If you need OCR, deskewing, or text extraction, a PDF splitter won’t help — those are different workflows. For batch automation in a build pipeline, install pdf-lib locally (npm i pdf-lib) and write a Node script — same engine, more control. For PDFs with PDF/A archive compliance requirements, use Adobe Acrobat or PDF Studio Pro to preserve the compliance metadata; pdf-lib outputs standard PDFs that may not validate as PDF/A. For password-protected files where you don’t have the password, no tool will help — that’s the security working as intended.

    Frequently asked questions

    Is my PDF uploaded?

    No. The splitter uses pdf-lib running in your browser. The file is loaded into a blob URL in your tab, processed locally, and the output is generated from the same in-memory data. You can verify in DevTools’ Network tab: dropping a file produces zero outbound requests.

    What’s the largest PDF I can split?

    Effectively your browser’s available memory. On desktop, files up to 200 MB and 1,000+ pages work. On mobile, the practical limit is around 50 MB. If a split fails, refresh the tab to free memory and try again with a smaller batch.

    Can I split a password-protected PDF?

    Yes — paste the user password in the prompt that appears when you upload. The splitter handles both user passwords (open access) and owner passwords (edit access). Password-protected files where you don’t know the password cannot be split — that’s the encryption working correctly.

    Does the split preserve form fields and signatures?

    Form fields and electronic signatures on extracted pages are preserved. Fields and signatures on dropped pages are removed (they wouldn’t be valid in the smaller file anyway). Visible certificate-based signatures from Adobe or DocuSign keep their visual representation; cryptographic validity depends on whether the signed scope changed.

    How do I split a PDF into individual pages?

    Pick the “Per page” mode. A 30-page input becomes 30 single-page output files in a ZIP. Useful for archiving multi-page invoices into one file per invoice, or pulling each scanned receipt out of a batch capture.

    Will splitting reduce the file size of each part?

    Roughly proportional to page count — splitting a 30 MB / 30-page PDF into 3 files yields three ~10 MB files. Embedded fonts and images are included only in the parts that reference them, so files with shared graphics may be slightly smaller than 1/N. To shrink further, run each output through a PDF compressor.

    Related tools and guides

     

  • Barcode Generator: Code 128, EAN-13, UPC, ITF [2026]

    Barcode Generator: Code 128, EAN-13, UPC, ITF [2026]

    TL;DR: A barcode generator turns a string of digits or alphanumeric characters into a scannable bar pattern in a chosen symbology (Code 128, EAN-13, UPC-A, Code 39, ITF, MSI). The right symbology depends on what you’re encoding: EAN-13 for retail products in Europe and most of the world, UPC-A for North American retail, Code 128 for shipping labels and inventory, ITF-14 for outer cartons. Our free barcode generator renders all of these in your browser as PNG or SVG.

    Barcodes look interchangeable from a distance but they’re a small zoo of incompatible standards. Use UPC-A on a European retail product and the supermarket scanner will reject it; use Code 39 on a shipping label and your carrier’s reader may not parse it. Picking the right symbology matters more than the visual styling. Once you’ve picked, generation is mechanical: encode your data, draw the bars, optionally add the human-readable digits underneath, export.

    Our barcode generator supports 8 symbologies covering 95% of real use cases — Code 128 (the modern default), EAN-13 / EAN-8 (retail global), UPC-A / UPC-E (retail North America), ITF-14 (outer cartons), Code 39 (legacy alphanumeric), and MSI (warehouse shelving). Outputs are scalable SVG (for print) or PNG (for screens). This guide covers which symbology to pick, the data formatting rules per type, and the print-quality details that make the difference between a barcode that scans every time and one that fails 5% of the time.

    Which barcode symbology should you pick?

    Symbology Best for Data type Length
    EAN-13 Retail products globally Digits 0-9 12 + 1 check digit
    UPC-A Retail in North America Digits 0-9 11 + 1 check digit
    Code 128 Inventory, shipping, internal IDs All ASCII Variable (1–80 typical)
    ITF-14 Outer shipping cartons Digits, even count only 14 fixed
    Code 39 Government, legacy systems A-Z, 0-9, -.$/+% Variable
    EAN-8 Small retail items (where EAN-13 won’t fit) Digits 0-9 7 + 1 check
    UPC-E Compressed UPC for small packaging Digits 0-9 6 + 1 check
    MSI Warehouse shelving Digits 0-9 Variable

    If unsure: pick Code 128 for internal use (it encodes every printable ASCII character compactly), and EAN-13 / UPC-A for retail. Don’t ship a Code 39 barcode in 2026 unless a partner system specifically requires it — it’s larger and lower density than Code 128 for the same data.

    Check digits — what they are, why they exist

    EAN-13, UPC-A, ITF-14, and others end with a check digit computed from the preceding digits using the GS1 modulo-10 algorithm: weight digits alternately by 1 and 3, sum, and pick the smallest digit that makes the total a multiple of 10. This catches single-digit errors and most transposition errors at scan time. Our generator computes the check digit automatically — paste 12 digits and we add the 13th — but you can override it if you’re reproducing a specific code that uses a different scheme.

    Code 128 has internal checksums built into the symbology; Code 39 has an optional mod-43 check digit (rarely used outside government).

    How to generate a barcode

    1. Open the barcode generator
    2. Pick a symbology (Code 128 if unsure)
    3. Enter your data — invalid characters are flagged as you type
    4. Adjust width, height, and “include text below” toggle
    5. Pick PNG (for digital use) or SVG (for print and labels)
    6. Click Download — the file appears in your browser’s downloads folder

    Print quality — the X-dimension rule

    Barcode print quality is governed by the X-dimension — the width of the narrowest bar. GS1’s published spec sets the X-dimension between 0.264 mm (10 mil) and 0.66 mm (26 mil) for retail. Print at less than 0.2 mm and scanners struggle; below 0.15 mm and scans fail outright. The barcode also needs quiet zones (blank margins) of at least 10× X on each side — squeeze the barcode into a tight box without quiet zones and scanners can’t find the start/stop characters.

    For a printed product label aim for X = 0.33 mm (13 mil); for a screen-only QR/ID barcode, any size that’s at least 200 px wide on a typical phone is fine. SVG output scales without loss, so prefer SVG for anything you’ll print.

    Common gotchas

    • EAN-13 and UPC-A are nearly identical encoding-wise. A 12-digit UPC-A is a 13-digit EAN-13 with a leading zero. Many EU scanners treat UPC-A as EAN-13 with a 0 prefix; some legacy US scanners specifically reject EAN-13 with a non-zero leading digit.
    • ITF-14 requires an even number of digits. 13-digit input is invalid; the symbology pairs digits to encode them. Our generator pads with a leading zero and recomputes the check digit.
    • Code 128 has 3 modes (A, B, C). Mode C compresses pairs of digits 2:1, halving the bar count for numeric strings. Our encoder picks the optimal mode automatically — you don’t need to choose.
    • “Standard 2 of 5” and ITF aren’t the same. Standard 2/5 is a different (rare) symbology. ITF (Interleaved 2 of 5) is the modern variant used for cartons.
    • Real product barcodes need a registered GS1 prefix. If you’re putting a EAN-13 on a product to sell in supermarkets, you must purchase a company prefix from GS1 (~$30/year for a single-digit prefix, ~$2,000+ for batches). Self-generated codes have no global guarantee of uniqueness.
    • Don’t shrink barcodes to fit a tiny package. Use a smaller symbology instead — EAN-8 or UPC-E are designed for small packaging. Squeezed full-size codes fail to scan.

    When NOT to use this tool

    For mass label printing (thousands of unique codes), use a desktop label printer driver that talks to your inventory system — Zebra ZPL, Brother P-Touch, Dymo. For commercial product distribution, register a GS1 company prefix and follow GS1’s barcode placement and quality guidelines. This generator is right for inventory tags, asset labels, internal tracking, prototype packaging, classroom demos, and one-off codes for a small business.

    Frequently asked questions

    What’s the difference between a barcode and a QR code?

    Barcodes are 1D (vertical bars only) and encode 10–80 characters. QR codes are 2D (a square grid) and encode up to 4,296 characters. Use a barcode for a product SKU or shipping label; use a QR code for a URL, contact card, WiFi credentials, or rich data.

    Can I use this for retail products I’ll sell?

    You can generate the visual, but for products sold via supermarkets and major retailers you must register a company prefix with GS1 to guarantee global uniqueness. Self-generated codes are fine for internal inventory; they’re not legally required to be globally unique unless you sell through a regulated retail chain.

    Why does my printed barcode fail to scan?

    Three usual suspects: (1) X-dimension too small — the bars are below the 0.2 mm threshold, (2) missing quiet zones — scanners can’t locate the start/stop, (3) low contrast — printer toner is faded or the surface is reflective. Print at 600 DPI minimum, leave 10× X margins, use matte paper with high-contrast ink.

    Should I use PNG or SVG?

    SVG for print — vector scales without loss at any DPI. PNG for digital use where SVG isn’t supported (some POS systems, embedded devices). Generate at 4× the display size if you go PNG, to allow zoom without aliasing.

    Is my data uploaded?

    No. The generator runs in your browser. SKUs, IDs, and product numbers stay on your device — useful when codes contain confidential information.

    Can I generate batches of barcodes?

    Yes — the tool offers a “batch mode” where you paste a list of values (one per line) and download a ZIP containing one image per line. Useful for inventory labelling and small-run product runs.

    Related tools and guides

     

  • Random Name Picker & List Randomizer Online [2026]

    Random Name Picker & List Randomizer Online [2026]

    TL;DR: A random name picker (or list randomizer) shuffles a list and either returns the full shuffled order or pulls a single random pick. The fair algorithm is the Fisher–Yates shuffle with a cryptographic random source — every input has equal probability of every output position. Our free list randomizer uses crypto.getRandomValues (cryptographically secure) and produces a shareable result URL so participants can verify the draw was honest.

    Picking a winner sounds simple until something goes wrong. A naive shuffle (sort with Math.random() - 0.5) is biased — some positions are 1.5–2× more likely than others — and you wouldn’t notice the bias unless you ran 10,000 trials. A weak random source means a savvy participant can, in principle, predict the outcome from prior draws. For a giveaway, raffle, or roommate chore wheel, neither is acceptable.

    Our list randomizer uses Fisher–Yates with the browser’s crypto.getRandomValues API — the same RNG used to generate cryptographic keys. The shuffle produces uniformly random results, and a shareable result URL lets you prove which order came out and when. This guide explains the fair-shuffle algorithm, the bias trap to avoid, and the use cases where a list randomizer is exactly the right tool.

    Use cases — where a randomizer fits

    Use case What you randomize Why fair matters
    Giveaway / raffle List of entrants → 1 winner Legal in most jurisdictions; bias = liability
    Team standup order List of teammates → speaking order Same person speaking last every day = morale issue
    A/B test variant assignment User IDs → variant A or B Biased assignment ruins the experiment
    Tournament bracket seeding List of players → bracket position Predictable seed = exploitable
    Classroom cold-call Roster → pick one student Equity — same students shouldn’t get picked
    Chore / pairing rotation List of people → assignment Reduces “always me” complaints

    The Fisher–Yates shuffle (and the bias trap to avoid)

    Fisher–Yates is the canonical unbiased shuffle. Walk the array from the last index down to the first; for each index i, pick a random index j in [0, i] and swap arr[i] with arr[j]. After one pass, every permutation is equally likely. It’s O(n) time and uses O(1) extra memory. Our randomizer implements it with crypto.getRandomValues for the random index, not Math.random().

    function fairShuffle(arr) {
  const a = [...arr];
  for (let i = a.length - 1; i > 0; i--) {
    const buf = new Uint32Array(1);
    crypto.getRandomValues(buf);
    const j = buf[0] % (i + 1);
    [a[i], a[j]] = [a[j], a[i]];
  }
  return a;
}

    The trap: sorting with arr.sort(() => Math.random() - 0.5) looks shuffle-ish but is provably biased. Different JS engines use different sort algorithms (V8 uses Timsort, JavaScriptCore uses MergeSort) and the comparator is inconsistent — the same pair returns different orderings on different calls. Tests show this approach favours the input order; some positions are 2× more likely than uniform. Never use sort-with-random for fairness-critical shuffling.

    How to randomize a list in your browser

    1. Open the list randomizer
    2. Paste your list (one item per line)
    3. Pick output: Shuffled order, Pick 1 winner, or Pick N
    4. Optional: set a seed for reproducible results (useful for “audit me later” draws)
    5. Click Shuffle — output appears with a shareable URL
    6. Copy the URL to send participants the verifiable result

    Seeded vs cryptographic shuffles — when to use which

    Default mode uses crypto.getRandomValues — non-deterministic, unpredictable, the right pick for live giveaways and competitions. Seeded mode uses a deterministic PRNG (xoroshiro128+) keyed off a string you provide. Same seed plus same input always produces the same output. Use seeded mode when you want to:

    • Audit later. Announce the seed in advance (“we’ll shuffle with seed 2026-01-launch at 5pm”). Anyone can re-run the shuffle later and verify the result.
    • Reproduce a result for testing. Useful for QA, classroom demos, or replaying a competition.
    • Coordinate across devices. Same seed on two laptops produces the same random pairing without communication.

    Don’t use seeded mode for high-stakes giveaways unless the seed is committed to publicly before the entry list is finalised — otherwise an organiser can choose a seed to favour a friend.

    Common gotchas

    • Modulo bias. Naive code does buf[0] % (i + 1) which is slightly biased when i + 1 doesn’t divide 2³². For lists under 1,000 items the bias is negligible (less than 1 in 4 million); for cryptographic uses, our randomizer rejects values above the bias threshold and resamples.
    • Duplicate entries. If your list has duplicates and you pick 1 winner, the duplicates increase the duplicate’s odds linearly. Dedupe first if you want one entry per person.
    • Whitespace trimming. “Maya ” (trailing space) and “Maya” are different entries by default. Our tool offers a “trim and dedupe” toggle to merge them.
    • Big lists. Lists of 1,000+ entries shuffle instantly. 100,000+ entries take a few hundred milliseconds — still real-time but the UI may briefly stall.
    • Live-stream rendering. If you’re showing the shuffle on a Twitch / Zoom screen, use the “animated reveal” mode — the result is determined first, then the items are revealed one at a time so spectators see a draw they can watch unfold.

    When NOT to use this tool

    For high-value lotteries, regulated giveaways, or anything where the outcome is legally binding, use a service that produces a notarised audit trail (Random.org’s signed-result API, or a third-party like Vlogging Heroes Sweepstakes). A free browser tool is great for community giveaways, classroom picks, and team rotations — it’s not a courtroom-grade randomness oracle. For programmatic use inside a Node.js script, use the standard library directly (crypto.randomInt) rather than reaching for an online tool.

    Frequently asked questions

    Is this random enough for a giveaway?

    For most community giveaways, yes — it uses crypto.getRandomValues, the same RNG behind cryptographic key generation. The output is unpredictable and uniform. For regulated lotteries with a legal audit trail, use a notarised service like Random.org’s signed API.

    How does the shareable result URL work?

    The full input list, the seed (if any), and the result are encoded in the URL. Anyone who opens the URL sees the same list and the same shuffled output, so participants can verify nothing was edited after the draw. The URL contains the data — there’s no server-side state.

    Can I run a shuffle that’s reproducible?

    Yes — pick “Seeded” mode and provide a seed string. Same seed plus same input list always produces the same output. Useful for classroom demos and for audited draws where the seed is announced in advance.

    What’s the maximum list size?

    Effectively your browser’s memory. Lists of 100,000+ items work but the page can briefly stall during shuffle. For most giveaways and team uses (a few hundred items at most), shuffle is instant.

    Is my list uploaded?

    No. The randomizer runs in your browser. Lists, seeds, and results are never uploaded to our servers — useful when the entrant list contains email addresses or other personal data you don’t want to share.

    What’s wrong with sorting an array with Math.random() - 0.5?

    It’s provably biased. The comparator is inconsistent (the same pair can return different orderings on different calls), which violates sort’s preconditions. Real test runs show some positions are 2× more likely than uniform. Use Fisher–Yates instead — it’s two lines longer and actually fair.

    Related tools and guides