A public blockchain is open for anyone to join, read, and transact on; a private blockchain restricts participation to an approved set of members. The choice shapes how decentralized, transparent, and fast the network can be, and it builds on how a blockchain works. The US National Institute of Standards and Technology uses the terms permissionless and permissioned for the same split.
Definitions
Public blockchains, like Bitcoin and Ethereum, are permissionless. Anyone can run a node or submit a transaction. Private, or permissioned, blockchains restrict who can participate, usually controlled by a company or consortium.
The distinction that actually matters is not who can read the data. It is who gets to decide what the data says. On a public chain, that right belongs to whoever shows up: download the software, meet the protocol's requirements, and you are a full participant, with no application to file and nobody who can revoke your access. On a private chain, someone maintains a list of approved participants and can add to it or remove from it. That list is the whole difference, and everything else follows from it.
A third category sits between them and is where most corporate deployments actually land. A consortium chain is run jointly by several organizations that do not fully trust each other but have a shared reason to cooperate, such as a group of banks or shipping companies. No single member controls it, but the group as a whole controls who else may join. It is permissioned, just with the permission held collectively rather than by one company.
Permission models
Public chains rely on open participation and broad consensus among independent nodes, which is why the number of independent nodes matters so much. Private chains grant access selectively, trading some decentralization for speed and control.
That trade is real in both directions, and it is not a case of one model being a compromised version of the other. Because a public chain has no idea who its participants are, it has to assume some of them are hostile, and it buys safety with expensive consensus: thousands of machines redoing the same work, plus mining or staking costs that make attacks uneconomic. That expense is what buys the guarantee that nobody can quietly change the rules.
A private chain already knows exactly who everyone is, and every participant is under a contract with a legal name attached. That changes the threat model completely. If a member cheats, they can be identified, removed, and sued, so the network does not need to make cheating mathematically impossible. It can use a much lighter agreement mechanism, which is why permissioned chains hit throughput figures public networks struggle to match. They are not solving the harder problem. They pushed most of it out to the legal system.
The costs of that choice are precise. A private chain's integrity rests on the honesty of its administrators, so the record is only as tamper-proof as the group running it, and if enough of them agree to rewrite it, it gets rewritten. The audit trail is genuine but it is not independently verifiable by anyone outside the club. For a shipping consortium reconciling paperwork, that is a perfectly reasonable bargain. For an asset you want to hold without anyone's permission, it defeats the purpose.
Examples
Bitcoin and Ethereum are the best-known public blockchains. A supply-chain tracking system shared among a handful of manufacturers is a typical private blockchain use case.
The pattern in production deployments is consistent. Permissioned chains show up where several organizations need one shared record and currently maintain separate ones that disagree: trade finance, freight documentation, interbank settlement, pharmaceutical provenance. The gain is not decentralization. It is that everyone reads from the same ledger instead of reconciling six databases by email, and every entry carries a signature and a timestamp nobody can quietly revise.
Public chains dominate wherever the point is that no single party is in charge. Every cryptocurrency you can actually buy and custody yourself, every open lending or trading protocol, and every asset whose value depends on a supply schedule nobody can amend lives on a permissionless network, because a permissioned version of any of them would just be a database with extra steps.
When each is used
Public blockchains suit situations that need censorship resistance and open verification, like holding an independent asset. Private blockchains suit organizations that want blockchain's record-keeping benefits without opening the network to the public.
A useful test is to ask who you would have to trust for the system to work, and whether that is acceptable. If the answer is "nobody in particular, because the rules are enforced by the network itself," you need a public chain and should expect to pay for it in fees and throughput. If the answer is "the six companies already in this consortium, all of whom I have contracts with," a permissioned chain is the honest fit, and the decentralization a public chain offers is a cost with no matching benefit.
For anyone approaching this as an investor rather than an architect, there is a practical takeaway worth carrying: the phrase "built on blockchain" in a company's marketing tells you nearly nothing on its own. A permissioned ledger run by the company selling it to you has none of the properties that make public chains interesting, and the word covers both.
The line between the two is also blurrier in practice than the categories suggest, and it is getting blurrier. Public chains often have permissioned components layered on top, and plenty of institutions now build on public networks while restricting who may use their particular application rather than running a separate chain. The useful question is rarely which label a project claims. It is which specific guarantee you are relying on, and who could take it away from you.