In more detail
Both sides share the key. The sender computes HMAC(key, message) and sends it with the message; the receiver recomputes it and compares. HMAC-SHA-256 signs API requests and webhooks, and HS256 JWTs use it. Compare the result in constant time, so that response timing does not leak how many leading bytes matched. HMAC wraps an ordinary Hash function in a fixed double-hash construction (key mixed in, hashed, then mixed in again and hashed), which is why it is safe where the naive hash(key + message) is not: SHA-256 used that way is exposed to length-extension attacks.
Why it matters
An HMAC proves two things at once: the message was not changed, and whoever produced it knew the secret key. A plain hash proves neither, because anyone can recompute it. The weak point is the key: if it leaks, anyone can forge valid tags, and because both sides hold the same secret, HMAC cannot prove which of them made a message (a public-key signature can).
Example
With the key secret and the message hello, HMAC-SHA-256 gives:
echo -n hello | openssl dgst -sha256 -hmac secret
88aab3ede8d3adf94d26ab90d3bafd4a2083070c3bcce9c014ee04a443847c0b
Change one letter of the message to hellp and the tag becomes f697fe1321f0e58b34f66af72d7225c580c985b904ef429e06da535c95511c45, so a receiver holding the key rejects it. Try other keys and messages with the HMAC Generator.
Common confusion
Do not mix it up with a plain Hash (no key) or a digital signature (two different keys, so anyone can verify but only the owner can sign).