GitHub BIP39 Word List: Official Files, Formats, Sources
Every cryptocurrency wallet that generates a seed phrase pulls from the same source: a standardized set of 2,048 English words defined by the BIP39 specification. Whether you're verifying a recovery phrase, building a tool, or just want to confirm that every word on your backup is legitimate, the GitHub BIP39 word list is the canonical reference developers and security-minded holders turn to first.
But GitHub hosts multiple repositories, forks, and file formats, raw .txt, JSON, numbered indexes, and more. Knowing which file is the official one and which format suits your needs matters, especially when a single wrong word during wallet recovery can lock you out of your funds permanently. That's the kind of detail FinTech Dynasty exists to clarify: practical, security-focused guidance without the noise.
This article breaks down exactly where to find the official BIP39 word list files on GitHub, what formats are available, how the list is structured, and how to use these resources safely for wallet recovery, verification, or development.
Why the BIP39 word list matters for self-custody
When you store cryptocurrency without a centralized exchange, your seed phrase is the only key that unlocks your funds. That seed phrase is not random gibberish; it is a precise sequence of 12 or 24 words selected from exactly 2,048 possible options defined by the BIP39 standard. The GitHub BIP39 word list is where that standard lives in its most accessible, developer-friendly form, and understanding why it matters starts with understanding what is actually at stake when you move into self-custody.
Your seed phrase is not a password
Most people treat their seed phrase like a password, something to store away and only use if they lose access. That mental model is dangerous. Unlike a password, your seed phrase cannot be reset, and there is no account recovery option if you lose it. There is no customer service team to call. If you lose or corrupt your seed phrase, every asset in that wallet is gone permanently.
This is why confirming that every word in your phrase belongs to the official BIP39 list is a foundational security step, not an optional one. A word that does not exist in the list signals either a transcription error during wallet setup or, worse, a tampered wallet or device. Catching that discrepancy early is far easier than discovering it at the exact moment you need to recover funds.
A single incorrect or misspelled word in a 24-word seed phrase will produce a completely different wallet, or no valid wallet at all.
Why the list itself needs to be verified
You are trusting your seed phrase to protect potentially significant value, which means you also need to trust the source of the word list you use for verification. A manipulated or unofficial word list could include words that appear valid but are not, creating a false sense of security. Pulling the list directly from the official BIP39 GitHub repository means you are working from the same source that wallet manufacturers and open-source developers use as their baseline.
Checking the word list against a verified, unmodified source is also the correct practice when you are building or auditing any tool that handles seed phrases. Wallet developers, security researchers, and technically minded holders all benefit from knowing exactly where the authoritative file lives and what format to request before doing any verification work.
What bad verification looks like
Some people attempt to verify a seed phrase word by typing it into a search engine or checking it against a random website. Both approaches carry real risk: search results can surface unofficial forks, outdated versions, or deliberately altered lists. Websites can be spoofed, compromised, or simply wrong.
Working from the raw text file on the official GitHub repository bypasses that risk entirely. It gives you a file you can inspect locally, hash for integrity, and reference fully offline. That kind of direct, verifiable access is exactly what responsible self-custody demands, and it is the standard approach used by professionals who build and audit wallet software at a production level.
What the BIP39 word list is and is not
The BIP39 word list is a fixed set of exactly 2,048 English words defined by Bitcoin Improvement Proposal 39, a technical standard published to make seed phrases human-readable and error-resistant. Every wallet that follows the BIP39 standard, which includes the vast majority of hardware and software wallets available today, draws from this same list when generating or restoring a seed phrase. Understanding what this list actually is, and what it is not, prevents common misunderstandings that can lead to security mistakes.
What the list actually is
The word list is a deterministic, versioned specification tied to a cryptographic process. When a wallet generates a seed phrase, it converts random entropy into a binary sequence, splits that sequence into groups of 11 bits, and maps each group to one of the 2,048 words in the list using positional indexing from 0 to 2047. The words were selected deliberately: they are all between 3 and 8 characters long, and no two words share the same first four letters, which reduces transcription errors when writing a phrase by hand.
The word list itself carries no private key information. It is simply a lookup table that makes raw binary data readable to humans.
The github bip39 word list in its English version is the reference implementation that wallet developers use. Each word maps to a specific index number, and that mapping is fixed. Changing even one word, swapping its position, or using a different capitalization breaks compatibility with every wallet that relies on the standard.
What the list is not
The BIP39 word list is not a password dictionary, a glossary, or a random collection of common words. The words were curated specifically to minimize visual and phonetic similarity between entries, reducing the chance of confusing one word for another during manual recovery. It is also not interchangeable across languages: the English list, the Spanish list, and the Chinese list are separate specifications, each with their own 2,048 words and their own index mappings.
The list is also not a security mechanism on its own. Knowing the word list does not help an attacker recover your wallet without also knowing the exact sequence and length of your specific phrase. The security comes from the astronomical number of possible combinations, not from the words themselves being secret.
Official GitHub sources for the BIP39 word list
Not all GitHub repositories hosting BIP39 word lists are equal. The github bip39 word list that developers and security researchers treat as authoritative comes from two specific repositories: the reference implementation maintained by Trezor and the formal specification housed in the Bitcoin BIPs repository. Knowing the difference between these sources and the forks that branch off from them is critical before you use any file for wallet verification or development.
The trezor/python-mnemonic repository
The trezor/python-mnemonic repository is the reference implementation of BIP39, maintained by the team that originally authored the proposal. This is where you find the English word list file at wordlist/english.txt, along with word lists for eight additional languages. The repository is publicly accessible on GitHub and represents the most directly cited source in production wallet software codebases, including those used by Ledger, Trezor, and many open-source wallet projects.
When in doubt about which repository to pull from, trezor/python-mnemonic is the one cited in the BIP39 proposal itself and used by the broadest range of production wallets.
You should always download the raw file directly from this repository rather than copying the word list from a third-party mirror or a cached page. The raw URL format on GitHub lets you retrieve a plain text file with no added formatting, one word per line, which is both the cleanest option for visual inspection and the most reliable input for any script or verification tool you are building.
The bitcoin/bips repository
The bitcoin/bips repository houses the formal BIP39 specification document itself, which is the authoritative written standard that defines how mnemonic phrase generation and recovery work at a technical level. While this repository does not host the word list as a standalone file in the same way, it provides essential context: the checksum rules, the entropy-to-mnemonic conversion process, and the full rationale behind every design decision baked into the standard.
Reading the BIP39 specification in the bitcoin/bips repository alongside the word list file in trezor/python-mnemonic gives you a complete and verifiable picture of the standard. If you ever find a discrepancy between a word list you located elsewhere and what the specification describes, the bitcoin/bips document is the definitive reference for resolving it.
Common formats and which one to use
The github bip39 word list is available in several file formats, and each serves a different purpose. Choosing the wrong format for your task will not break anything, but it will add unnecessary steps, and in a security context, unnecessary steps mean unnecessary risk. Understanding the differences up front lets you pull exactly the file you need the first time.
Plain text (.txt)
The .txt file is the most widely used format and the one you should start with unless you have a specific technical reason to do otherwise. In the trezor/python-mnemonic repository, the English word list lives at wordlist/english.txt and contains all 2,048 words, one per line, with no index numbers, no punctuation, and no extra whitespace. That simplicity is a feature: a plain text file is trivial to inspect visually, easy to hash for integrity verification, and compatible with virtually every programming language and command-line tool without any parsing step.
If your only goal is to verify that a word belongs to the official BIP39 list, the plain text file is the fastest and most reliable option available.
Building a script to validate seed phrases becomes straightforward when you read the .txt file line by line, since it gives you a clean array with no transformation required. You can load it, sort it, binary-search it, or grep it in seconds. For anyone working on wallet verification or audit tooling, this format is the correct default choice.
JSON format
JSON versions of the word list exist in various repositories and community projects, but you will not find an official JSON file in the trezor/python-mnemonic repository itself. That distinction matters before you pull a JSON file from a fork or third-party source. JSON formats are useful when you are building a web-based or JavaScript-driven application that needs the list available as a structured data object, but they introduce one additional concern: you need to confirm that the JSON file contains exactly the correct 2,048 words in the correct order, since any fork could have introduced unintentional or deliberate modifications.
Generating the JSON yourself by parsing the official .txt file programmatically is the safest path if you need that format. That approach gives you full control over both the source data and the transformation process, so you are never trusting a secondary file that may have quietly diverged from the canonical list.
How indexing works and how to avoid off-by-one errors
Every word in the BIP39 list occupies a specific numbered position, and that position is what wallets actually use when converting between binary entropy and a human-readable phrase. When you pull the github bip39 word list from the trezor/python-mnemonic repository, the raw .txt file lists words sequentially from line 1 to line 2048, but the BIP39 specification itself indexes them from 0 to 2047. That single-digit gap between how the file is presented and how the standard defines positions is the source of most off-by-one errors in wallet tooling.
Zero-based vs one-based indexing
The BIP39 standard uses zero-based indexing, meaning the word "abandon" sits at index 0 and the word "zoo" sits at index 2047. When you read the .txt file in most text editors or with standard file-reading functions, the first line is line 1, not line 0. That means if your code reads the file and stores words by line number without subtracting one, every index lookup will be off by exactly one position across the entire list.
Treating line numbers as BIP39 indexes without adjusting for zero-based counting will silently produce incorrect results in any tool that maps entropy bits to words.
The table below shows how the boundary words map across both systems:
| BIP39 Index (0-based) | Line Number in .txt file | Word |
|---|---|---|
| 0 | 1 | abandon |
| 1 | 2 | ability |
| 2047 | 2048 | zoo |
Practical checks to avoid off-by-one errors
When you build or review any script that reads the word list, verify the first and last entries explicitly before running any real phrase validation. Load the file, pull index 0, and confirm it returns "abandon." Pull index 2047 and confirm it returns "zoo." Those two checks take seconds and will immediately surface any indexing mistake in your implementation.
You should also test round-trip conversion using a known valid seed phrase. Take a phrase generated by a wallet you trust, convert each word to its BIP39 index, then convert those indexes back to words. If the output matches the original phrase exactly, your indexing logic is correct. If any word shifts by one position during the round trip, the off-by-one error is in your file-reading logic rather than your lookup function, and you can isolate and fix it before the tool touches anything sensitive.
BIP39 languages on GitHub and how to identify them
The github bip39 word list is not limited to English. The trezor/python-mnemonic repository includes nine language-specific word lists, each containing exactly 2,048 words mapped to their own independent index system. Choosing the correct language file matters because wallets tied to a specific language expect that exact word set during recovery. Mixing a Spanish-language phrase with an English word list will return no valid wallet, and doing the reverse produces the same result.
The languages available in trezor/python-mnemonic
Each language file in the repository lives inside the wordlist/ directory and follows the same naming convention: the language name in lowercase followed by .txt. The nine available languages are:
- English (
english.txt) - Spanish (
spanish.txt) - French (
french.txt) - Italian (
italian.txt) - Japanese (
japanese.txt) - Korean (
korean.txt) - Chinese Simplified (
chinese_simplified.txt) - Chinese Traditional (
chinese_traditional.txt) - Czech (
czech.txt)
The English list remains the default across nearly every major hardware wallet, meaning that unless your wallet setup explicitly selected a different language, your seed phrase almost certainly draws from
english.txt.
Each non-English list was built with the same constraints applied to the English version: words are distinct in their first four characters, and every list was reviewed to minimize confusion between visually or phonetically similar entries. Japanese and Korean files use their native character sets, so if you open those files and see only placeholder boxes or broken characters, your text editor does not support the required encoding rather than the file being corrupt.
How to confirm you are using the correct language file
Your wallet documentation is the first place to check for language confirmation. Most hardware wallet setup guides state explicitly which word list language was used during initialization. If that documentation is unavailable, you can cross-reference the words in your seed phrase against each available .txt file systematically until every word matches a single list without exception.
When every word in your phrase appears in one file and only one file, you have identified the correct language and the correct source. If words from your phrase appear across two different language files, that points to a corrupted or incorrectly recorded phrase rather than a language ambiguity, and you should retrace your original backup process before attempting any recovery.
Security pitfalls when using BIP39 word lists
Working with the github bip39 word list for verification or development introduces specific security risks that are easy to overlook, especially when you are focused on getting the technical work done. Understanding where these risks appear before you start protects both your funds and any tool you are building for others.
Downloading from unofficial sources
The most common mistake people make is pulling a word list from a fork, mirror, or third-party repository instead of going directly to trezor/python-mnemonic. Forks can diverge from the canonical source in ways that are invisible at a glance: a single swapped word, a reordered entry, or a subtle character substitution in a non-English list. Any of those changes will break compatibility with real wallets and give you false confidence that your verification tool is working correctly when it is not.
Always compare the SHA-256 hash of any downloaded word list file against a hash computed from the official raw file on trezor/python-mnemonic before using it in any security-sensitive context.
You should also avoid cloning repositories from unknown contributors who have published their own BIP39 tooling without a clear audit trail. A repository that wraps the word list inside additional scripts creates an opportunity to introduce malicious logic, even if the word list contents themselves appear correct. Keep the word list file separate from any tooling you did not write yourself.
Entering your seed phrase into online tools
Some online validators and seed phrase checkers ask you to type your actual recovery phrase into a web form to verify it. You should never do this. Any website that receives your seed phrase over the internet, regardless of how legitimate it appears, creates a potential attack surface. Your phrase can be intercepted in transit, stored server-side, or exfiltrated through browser extensions without leaving any visible trace.
The correct approach is to verify words individually against the word list rather than submitting your full phrase anywhere. Check whether each word exists in the list, confirm the total word count matches your wallet's expected length, and perform any deeper validation using local scripts that run entirely offline on a device that has never touched the internet during the session. That process gives you full verification capability without exposing your recovery phrase to any external system.
Key takeaways
The github bip39 word list in the trezor/python-mnemonic repository is the canonical source for wallet verification and development work. Always pull the raw .txt file directly from that repository rather than from forks, mirrors, or third-party tools that may have quietly diverged from the standard.
Your seed phrase maps to a zero-based index, so any script you write needs to account for that one-position gap between line numbers and BIP39 positions. Verify "abandon" at index 0 and "zoo" at index 2047 before trusting any tool you build. Never enter your full phrase into an online validator, and always perform verification locally and offline to avoid exposing your recovery phrase to external systems.
Nine language lists exist in the repository, but English is the default for nearly every major hardware wallet. If you want to build a stronger foundation around self-custody and crypto security, start with the FinTech Dynasty crypto education course.