SLIP39.app

Your mnemonic's underlying entropy becomes the constant term of a random polynomial over a finite field; each share is one point on that polynomial. With fewer points than the threshold, every possible secret remains equally likely — this is information-theoretic security, not just “hard to crack”. The share format is SLIP-0039, the SatoshiLabs standard also used by Trezor hardware wallets, so your shares are portable across implementations. Each share carries its own checksum, and the share set embeds a digest so recovery can prove the shares are consistent and complete. The legacy Shamir39 format (iancoleman.io/shamir39) is supported for recovering older share sets.

• Generate — create a fresh 12/24-word BIP39 mnemonic. Randomness mixes your operating system's CSPRNG with over 1024 bits of entropy gathered from your own mouse movement, so no single source has to be trusted.
• Split — turn an existing mnemonic into an n-of-m SLIP-0039 (or legacy Shamir39) share set, with an automatic self-check that recombines a random quorum before you rely on it.
• Recover — paste shares (format auto-detected, validated as you type) to restore the mnemonic, then verify it by deriving known addresses.
• Info — inspect any mnemonic: account xpubs and first addresses for Bitcoin (legacy, wrapped and native SegWit), Ethereum, TRON and Solana, plus a resolver for arbitrary derivation paths.

1. Verify the file hash (see the security status below), then go offline — airplane mode or unplug. The page cannot make network connections either way, but defense works in layers.
2. Generate a new mnemonic, or bring your existing one.
3. Split it — pick how many shares to create (m) and how many are needed to recover (n). Write each share on paper or steel; avoid the clipboard and printers.
4. Distribute the shares to separate places or people. No single share (below the threshold) is a risk on its own.
5. Do a recovery drill with a throwaway mnemonic first, and confirm the derived addresses match your wallet before trusting any backup.
6. When done: Wipe session, close the tab, reboot.

No web page that handles wallet keys deserves blind trust — including this one. Instead of asking for your trust, this tool is built so you can replace trust with verification:

• Read the code. The full source lives at github.com/pk910/slip39.app — plain, readable JavaScript with zero dependencies: no frameworks, no CDNs, no package manager, nothing loaded at runtime. There is no build tooling that could inject code; what you audit is what runs.
• Verify the file you're using. The release is a single HTML file. Compare its hash — sha256sum index.html — against SHA256SUMS in the repository. Inside the file, CSP hashes additionally pin the inline script and stylesheet to the byte.
• Reproduce the release. The build is a deterministic concatenation of the audited source files (node scripts/build-release.mjs, Node built-ins only). Clone the repository, build it yourself, and diff your output against the published file.
• Run the test suite. npm test pins every cryptographic primitive to the official test vectors of its specification (SLIP-0039, BIP-32/39/84, SLIP-0010, RFC 8032 and more) — no installs needed.
• Watch it at runtime. A strict Content-Security-Policy makes network requests impossible (check the Network tab of your browser's dev tools — it stays empty), and the security status below reports tampered browser built-ins.

If you cannot audit it yourself, ask someone you trust to, or use it only from an offline, freshly booted machine with a clean browser profile — and rehearse with a throwaway mnemonic before ever touching a real one.

Lost: as long as any n of your m shares survive, you can recover — that's the point of choosing n < m. Stolen: an attacker with fewer than n shares learns nothing at all; consider re-splitting and re-distributing if a share is exposed.

Yes — shares are standard SLIP-0039 and can be entered during Trezor recovery. Note the direction matters: this tool splits the mnemonic's entropy, so recovering on other tools yields the same BIP39 mnemonic, not a different wallet.

It encrypts the share set. By design a wrong passphrase silently produces a different, valid-looking mnemonic (plausible deniability) — there is no error message. If you use one, you must remember it exactly, and you should verify recovered wallets via their derived addresses.

With a threshold of 1, every single share alone reveals the secret — that's a copy, not a split, and SLIP-0039 forbids it. Store multiple copies of a 1-of-1 share if replication is really what you want.