Overlap exists to solve one specific problem: a passage that straddles a chunk boundary is retrievable from neither chunk. The sentence that begins at the end of chunk four and finishes at the start of chunk five appears complete in no embedding, so a query matching it matches nothing well.
Repeating the last portion of each chunk at the start of the next means any passage shorter than the overlap appears complete somewhere. That is the whole mechanism, and it explains how to size it: the overlap should be at least as long as the passages you care about retrieving intact — typically a sentence or two.
In practice, ten to twenty per cent of chunk size resolves this for most prose. A five-hundred-character chunk with fifty to a hundred characters of overlap covers a sentence comfortably.
Past about half the chunk size, overlap stops helping and starts costing. Most of each chunk is then a copy of its neighbour. Your index grows for no additional coverage, embedding cost rises in proportion, and retrieval returns several near-identical chunks that crowd out genuinely different material. A query that should surface three distinct passages instead surfaces one passage three times.
Overlap also interacts with your chunking strategy. If you are splitting on paragraph boundaries, chunks already end at natural breaks and mid-thought cuts are rare, so less overlap is needed. Fixed-size chunking cuts wherever the counter lands, so it benefits more.
The most reliable way to size overlap is to look at the boundaries. Set a value, look at where consecutive chunks actually begin and end against the original text, and check whether the duplication is buying you anything. If neighbouring chunks read as substantially the same content, the overlap is too high regardless of what any rule of thumb says.