The short answer
A fork is a change to the rules that decide whether a block is valid, and it takes exactly two shapes.
A soft fork makes the rules stricter. Software that was never updated still accepts every block produced under the new rules, because those blocks were already valid under the old ones.
A hard fork makes the rules looser. Software that was never updated rejects the first block that uses the new freedom, because by its rules that block is simply wrong.
BIP 123, which classifies proposals by the layer they touch, puts it in two sentences: in a soft fork, "some structures that were valid under the old rules are no longer valid under the new rules", while in a hard fork, "structures that were invalid under the old rules become valid under the new rules". Everything below follows from that.
A consensus rule is a rule about validity
Not every rule a node follows is a consensus rule. Bitcoin Core's policy documentation draws the line: relay policy is "local to the node and configurable", applies only to unconfirmed transactions, and is "not applied to transactions in blocks" (doc/policy/README.md). A node that will not relay a transaction is expressing a preference. A node that will not accept a block is doing something else.
Consensus rules answer whether a block is part of the chain at all. A block whose weight exceeds 4,000,000 units is invalid (BIP 141); a coinbase transaction that does not commit to the block's own height is invalid (BIP 34). Every node you run checks these itself and discards what fails, however much work went into it and whoever produced it. Disagree about policy and you relay slightly differently. Disagree about consensus and you are not looking at the same chain.
Who has to upgrade
Take the weight limit both ways. Cap blocks at 2,000,000 units instead of 4,000,000 and every block satisfying the new rule satisfies the old one too, so a node running last year's software accepts the chain without noticing. Raise the cap to 8,000,000 and the first block using the extra room is invalid to every node still running old software.
BIP 99, which sets out the deployment paths for consensus changes, states the consequence flatly: a soft fork means "a hashrate majority of miners can impose the new rules", and hard forks "require all users to upgrade".
So under a soft fork an unupgraded node keeps following the chain without being asked, and never has to know. That is why one can be deployed while much of the network runs old software, and it is also the uncomfortable part: such a node is kept in consensus by other people's enforcement rather than its own. A hard fork extends no such courtesy, and one that most people do not adopt does not fail quietly. It produces a second chain.
A chain split, and when it stops being temporary
Short-lived splits happen constantly and have nothing to do with rule changes: two miners find a block at nearly the same moment, and the tie resolves when the next block extends one of them. Every node applied the same rules throughout. A rule disagreement is a different object. BIP 99 calls the deliberate version a schism hard fork, defined as the case where "users are consciously going to validate 2 different sets of consensus rules", with the result that "they will end up following 2 different chains for at least some time, maybe forever". Whether it is forever depends on the direction of the change.
After a hard fork, permanence is structural: the new chain's blocks are invalid to old nodes and can never be reorganised into their chain, however much work accumulates behind them. Chains that intend to leave often make this explicit. The specification for the August 2017 Bitcoin Cash fork required its very first block to exceed 1,000,000 bytes, and gave the reason: it "enforces the hard fork from the original 1MB chain and prevents a re-organization of the forked chain to the original chain" (UAHF technical specification, REQ-3, version 1.6, 24 July 2017).
After a soft fork split it is not, because the strict chain's blocks stay valid to everyone. The split exists only for the nodes doing the extra enforcement, and lasts only while they keep choosing a chain other nodes would abandon for one with more work. BIP-110's mandatory signalling window showed both halves in August 2026: nodes enforcing the proposal left the main chain the moment a block arrived without the required version bit, and mining on the new chain then stalled. The stalling was arithmetic. Difficulty only retargets every 2,016 blocks, so a chain that splits away inherits the whole network's difficulty with only the hashrate that came with it, and must mine 2,016 blocks at that setting before it can adjust.
Replay, and why a split chain usually adds protection
Both chains share every block before the split, so every coin that existed beforehand exists on both, spendable by the same key under the same script. That is convenient right up to the moment it is not. A transaction signed to move coins on one chain is, byte for byte, a valid transaction on the other, and anyone can broadcast it there. This is a replay, and it needs no special access: the transaction is already public and already valid.
The fix is to make the two chains disagree about what a signature covers. Bitcoin Cash required, at consensus, that every transaction set a new flag in its hash type and be signed with a modified digest algorithm, so a signature made for one chain does not verify on the other. The specification gives the purpose in one line: "to provide strong protection against replay of existing transactions" (UAHF technical specification, REQ-6-2).
Somebody has to build that, and it is not automatic. A November 2017 bitcoin-dev proposal for a general mechanism opened by describing the state of practice: "Currently when a hard fork happens, there is ad-hoc replay protection built within days with little review at best, or no replay protection at all" (Mats Jerratsch, 5 November 2017).
How a rule actually gets turned on
A change has to start being enforced at a moment every node agrees on, and there is more than one way to pick it.
BIP 9 signals through the block header. Each deployment gets a bit in the version field, a start time and a timeout. Once started, if at least 1,916 blocks in a 2,016-block retarget period set the bit, which is 95 percent, the deployment moves to LOCKED_IN for one further period and then to ACTIVE; if the timeout passes without lock-in it is FAILED (BIP 9). The bit is miners saying they are ready to enforce, not voting on whether the rule is a good idea, and BIP 9 treats a shortfall as failure rather than rejection.
BIP 8 keeps the idea and changes the parts that bit. Start and timeout are block
heights rather than timestamps, because "block time is somewhat unreliable"; the suggested
threshold is 1,815 blocks, or 90 percent; and a minimum_activation_height lets lock-in
and activation be separated by as long as node operators need. Its motivation names the
problem with BIP 9 directly: activation "dependent on near unanimous hashrate signalling
which may be impractical and result in veto by a small minority of non-signalling hashrate"
(BIP 8).
Its distinctive part is the lockinontimeout flag. Set it and the deployment enters a
MUST_SIGNAL period before the timeout, in which blocks that fail to signal are rejected as
invalid, so the fork locks in by the deadline whatever miners do. BIP 8 says when to use
it: for any soft fork "expected or found to have political opposition from a non-negligible
percent of miners".
A user-activated soft fork drops the negotiation. Nodes begin enforcing on a fixed date and reject blocks that do not comply, and miner signalling stops being the trigger. BIP 148 is the worked example: from 1 August 2017, every block had to signal for the existing SegWit deployment, and "blocks that do not signal as required will be rejected". Its cited precedent was much older than the argument it belonged to, since pay-to-script-hash was activated on a flag day, its rules applying to every block timestamped on or after 1 April 2012 (BIP 16).
The mechanism does not decide whether a mandatory rule is safe or reckless. A node enforcing a rule the rest of the network ignores gets a chain of its own: the point when it works, the cost when it does not. Most activations are duller than that, and Taproot's produced no split at all.
What a fork does not do
It does not change anyone's coins. Both chains inherit the same history, so an output that existed before the split still exists after it, holds the same amount, and is spendable by the same key. A fork can create a second place where a copy of a balance exists. It cannot reach into the first one.
Running old software does not put you on a new chain. After a soft fork, old software follows the same chain as everyone else without being asked, which is the definition of the thing. After a hard fork, old software stays on the chain it already considered valid and rejects the new one. Ending up on a new chain takes a deliberate act: installing software that implements rules the previous software refused.
Signalling is not a vote. Miners choose which valid transactions to put in blocks. Nodes decide what valid means. A hashrate majority can enforce a tightening, and it cannot make a loosening acceptable to anybody who did not install it.
Where to go next
SegWit and what a block weighs explains how a soft fork managed to change the effective capacity of a block at all, which is the case most often mistaken for a size increase. For the history in which all of this was decided rather than described, the block size war produced most of the vocabulary on this page.