Incident brief
Invalid byte sequence for encoding
Interpreting bytes as text in a given encoding fails when the bytes are not valid there; 0xff is never a valid standalone UTF-8 byte.
What lands in your log
ERROR: invalid byte sequence for encoding "UTF8": 0xff
In 10 seconds
- What triggers it
- Call convert_from(bytea, encoding) where the bytes are not valid in the stated encoding.
- Fix
- Feed bytes that are actually valid in the declared encoding.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 22021; the byte 0xff is rejected as invalid UTF-8.
Fix
What to do right now
Application-level steps for this error.
- Feed bytes that are actually valid in the declared encoding.
- If the true encoding differs, decode with the correct one (for example LATIN1) instead of UTF8, or sanitize the input first.
-- Decode only bytes that are valid in the target encoding.
SELECT convert_from('\x41'::bytea, 'UTF8');For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Invalid byte sequence for encoding is an encoding-boundary failure. Capture the original bytes before any lossy application decode, then confirm client/server encodings.
Effective encodings for the rejected byte stream
Read the encoding contract PostgreSQL is enforcing.
SELECT current_setting('client_encoding') AS client_encoding,
current_setting('server_encoding') AS server_encoding;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 18 Documentation, Appendix A. PostgreSQL Error Codes (Table A.1, Class 22, Data Exception)
22021 → character_not_in_repertoireRead the full section on postgresql.org →
Decoding an invalid byte as UTF-8
0xff cannot appear in a valid UTF-8 sequence, so PostgreSQL raises 'invalid byte sequence for encoding UTF8: 0xff'.The session continues normally
This byte-sequence check failed as a standalone statement; with no transaction open, session B's next query is unaffected.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Call convert_from(bytea, encoding) where the bytes are not valid in the stated encoding.
- 2PostgreSQL decodes the bytes and reaches 0xff, which cannot begin or continue a UTF-8 sequence.
- 3The decode aborts with SQLSTATE 22021 and 'invalid byte sequence for encoding UTF8: 0xff'.
A byte column captured from a mixed-encoding upstream was decoded as UTF-8 and failed on the first non-UTF-8 byte.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT convert_from('\xff'::bytea, 'UTF8');SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: invalid byte sequence for encoding "UTF8": 0xff session_after_error
---------------------
ok
(1 row)A byte that is valid in the encoding decodes to its character without error.
Without this
Before: 0xff is not valid UTF-8
With this, tested
After: 0x41 decodes to 'A'
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-24 (isolated lab, PostgreSQL 18.4)
- Verification scope
- Verified against PostgreSQL 18.4 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.