SEC 1 §2.3.3 defines the octet strings used almost everywhere: uncompressed 0x04 ‖ x ‖ y (65 bytes for P-256 and secp256k1, 97 for P-384, 133 for P-521) and compressed 0x02 ‖ x or 0x03 ‖ x, where the prefix gives the parity of y (33, 49 and 67 bytes). Decoding a compressed point solves the curve equation for y, and a decoder must reject an x with no valid y.
Which form you meet depends on the ecosystem: X.509 SubjectPublicKeyInfo almost always carries uncompressed points (RFC 5480 requires support for them and makes compressed ones optional), WebCrypto raw import accepts both for ECDSA keys in modern browsers, Bitcoin has used 33-byte compressed keys since about 2012, and Ethereum derives addresses from the 64 bytes of x ‖ y without the 0x04 prefix. JWKs always carry separate x and y members.
Edwards and Montgomery encodings are compressed by construction: an Ed25519 public key is the 32-byte y-coordinate with the sign of x in the top bit, and X25519 transmits only u. A mismatch between a 33-byte and a 65-byte key is a common cause of "invalid public key" and "point is not on the curve" errors.