Depending on if you're shopping for the server or the client side of the implementation, I actually found the RFC's example section was actually helpful https://datatracker.ietf.org/doc/html/rfc7636#appendix-B The only thing that jammed me up, even while preparing this comment, is that they named both parameters very similar to one another which is :-(

One can think of the whole exchange as a way for the client to prove future knowledge, but only actually transmitting the held back "secret" during token redemption. Let's use just a random integer

1. r = randomInt()

2. future = base64(sha256(r))

3. /authorize?client_id=cid-123&code_challenge_method=S256&code_challenge=${future}

The server has to retain the ${future} in durable storage, because it's going to need access to it, plus the ${code} that it's about to return, in step 5

4. <-- &code=abc789

5. /token?code=abc789&code_verifier=${r}

Now, the server can repeat that same sha256 dance from step 2 and establish that the client presenting "r" means it really was the same requester in step 3, because no one else, even with that same IP address and same access to the client_id sniffed in transit, could have known "r" for sufficiently random values of "r", thus proving their key during code exchange