In the OAuth authorisation code flow, the provider sends the user back to your app with a one-time code in the URL, and your app swaps that code for tokens. Browser apps and mobile apps cannot keep a client secret, so on their own they have no way to prove that the party redeeming the code is the one that started the login. A malicious app or script that captures the code could redeem it first.
PKCE closes that gap. Before redirecting, the app creates a random value called the code verifier and sends only a hash of it, the code challenge, with the login request. When it later exchanges the code, it must present the original verifier. The server hashes it and compares. An attacker holding only the intercepted code cannot complete the exchange. PKCE is defined in RFC 7636, and the current OAuth security guidance in RFC 9700 recommends it for the authorisation code flow generally.
You rarely write PKCE yourself. It is a setting or a default in your auth library. What matters is that it is on, that the challenge method is S256 rather than plain, and that you are not using the older implicit flow, which returns tokens directly in the URL.
https://accounts.example.com/authorize?response_type=code&client_id=YOUR_ID&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256