There is no universally correct chunk size, and any article offering one number is guessing on your behalf. What there is, is a trade-off you can reason about and then test against your own material.
Small chunks retrieve precisely. A two-hundred-character chunk matching a query is almost certainly about that query. But it often lacks the context that makes it useful: a sentence describing a configuration option, retrieved without the paragraph explaining what the option is for, may be accurate and still unhelpful to the model reading it.
Large chunks carry context and retrieve bluntly. A two-thousand-character chunk contains the surrounding explanation, but matches a wider range of queries less precisely, and fills the context window with material that is mostly irrelevant to the specific question.
The practical range for prose is usually somewhere between three hundred and eight hundred characters, but the structure of your material matters more than the number. Documentation with short, self-contained sections chunks well at natural boundaries. Continuous narrative prose does not, and needs overlap to avoid cutting mid-argument. Reference material with dense tables often needs a different approach entirely.
Choose a strategy before choosing a size. A recursive strategy that respects paragraph boundaries produces chunks of varying length that mostly end where a thought ends. A fixed-size strategy produces predictable lengths and cuts wherever the counter lands, sometimes mid-word. For most prose the first is better, and the variance in chunk length is a feature rather than a problem.
Then test it. Run your actual corpus through two or three settings and read the chunks. Boundaries that land mid-sentence, chunks that consist mostly of a heading, and chunks that duplicate their neighbour are all visible immediately and invisible in any aggregate metric.