My contribution to add base64url encoding and decoding support has been accepted and merged into PostgreSQL. This new feature provides a safe and efficient way to handle binary data in URLs and filenames directly within the database. Here’s the commit and the relevant discussion.

SELECT encode('\xdeadbeef'::bytea, 'base64url'); -- 3q2-7w

SELECT decode('3q2-7w', 'base64url'); -- \xdeadbeef

-- Attempt to decode the same base64url string with plain base64 (will ERROR)
SELECT decode('3q2-7w', 'base64');
-- ERROR:  invalid symbol "-" found while decoding base64 sequence

If you’ve ever dealt with binary data in a web context, you’ve likely encountered base64 encoding. It’s a standard way to represent binary data as a string of ASCII characters. However, standard base64 has a small but significant problem: its alphabet includes the + and / characters. These characters have special meanings in URLs and file systems, often requiring additional URL encoding to be used safely.

This is where base64url comes in. Defined in RFC 4648 Section 5, base64url is a variant of base64 that solves this exact problem. It replaces the problematic + with - and / with _, making the encoded string perfectly safe for use in URLs, filenames, and other contexts where these characters are reserved.

Another key difference is that base64url omits the = padding characters. While this isn’t strictly necessary for safety, it results in a more compact string, which is often a nice bonus.

This should be available in PostgreSQL 19; expected to be released in September 2026.

Thanks to the reviewers for their feedback and suggestions on this patch and to Przemysław Sztoch for proposing it.