Why a certificate and key might not match
A web server needs a certificate and its matching private key installed together - if they come from different requests (an old key paired with a renewed certificate, for example), the server will usually fail to start or clients will see connection errors. This checks whether the public key embedded in the certificate corresponds to the private key you paste in, without needing to deploy anything first.
How the match is actually determined
Every certificate embeds a public key, and every private key has a corresponding public key that can be derived from it mathematically - the check works by deriving the public key from your pasted private key and comparing it against the public key embedded in the certificate. A match confirms the two were generated as a genuine pair; any mismatch means they weren't.
When this check is most useful
Catching a mismatched pair before deploying it to a live server avoids a confusing production outage - this is especially worth running after a certificate renewal (confirming the new certificate pairs with the key you intend to keep using), or when consolidating certificate files from different sources where a mix-up is easy to introduce.
Handling an encrypted private key
Private keys are sometimes stored encrypted with a passphrase for extra protection at rest - if yours is encrypted, the tool needs that passphrase to actually read the key before it can derive its public key for comparison, which is why the passphrase field exists as a separate, optional input alongside the key itself.