BIO_F_BASE64(3ossl)

💖 BIO_F_BASE64 💖

okay bestie, gather round, because today we're talking about BIO_f_base64 — the base64 BIO filter from OpenSSL 🦋. It lives in section 3ossl of the manual, and it's genuinely one of the cutest little filters in the whole crypto toolbox. let's get into it ✨

---

🌸 NAME 🌸

BIO_f_base64 — it's the base64 BIO filter, no cap 💅

---

✨ SYNOPSIS ✨

#include <openssl/bio.h>
#include <openssl/evp.h>

const BIO_METHOD *BIO_f_base64(void);

---

🎀 DESCRIPTION 🎀

So BIO_f_base64() hands you back the base64 BIO method. It's a filter BIO, which basically means it sits in the middle of your chain and transforms everything passing through it 🧚 — base64 encodes anything you write through it, and decodes anything you read through it. main character behavior honestly.

💀 heads up: base64 BIOs do not support BIO_gets() or BIO_puts(). they just don't. don't try it.

For writing ✍️ — by default, the output gets split into lines of length 64 characters, and there's a newline at the end of the output. You can change that whole vibe with the BIO_FLAGS_BASE64_NO_NL flag.

For reading 📖 — the first line of base64 content should be at most 1024 bytes long, including the newline, unless the BIO_FLAGS_BASE64_NO_NL flag is set. After that first line? Anything goes, bestie — subsequent input lines can be of any length (so like, newlines may appear anywhere in the input) and you don't even need a newline at the end of the input. slay.

Also, still on the reading side 🫶 — unless BIO_FLAGS_BASE64_NO_NL is set, initial lines that contain non-base64 content get skipped (whitespace is tolerated and ignored, so it's fine, it's giving invisible ✨), and so do lines longer than 1024 bytes. Decoding starts with the first line that is shorter than 1024 bytes (including the newline) and consists of only (at least one) valid base64 characters plus optional whitespace.

And decoding stops when any of these happen:

• base64 padding is encountered 🎀
• a soft end-of-input character (-, see EVP_DecodeUpdate(3)) occurs as the first byte after a complete group of 4 valid base64 characters is decoded
• an error occurs (e.g. due to input characters other than valid base64 or whitespace) 😭

⚠️ if decoding stops as a result of an error, the first BIO_read(3) that returns no decoded data will typically return a negative result, rather than 0 (which is what indicates normal end of input). BUT — and this is important — a negative return value can also occur if the underlying BIO supports retries. see BIO_should_read(3) and BIO_set_mem_eof_return(3). so don't jump to conclusions, okay?

BIO_flush() on a base64 BIO that's being written through is used to signal that no more data is to be encoded — this is what flushes that final block through the BIO. it's the "okay we're done here" of the whole operation 💅

The flag BIO_FLAGS_BASE64_NO_NL can be set with BIO_set_flags(). Here's the tea:

• For writing — it causes all data to be written on one line without a newline at the end. one line. no newline. iconic.
• For reading — it removes all expectations on newlines in the input data. free yourself 🌈

---

📝 NOTES 📝

Because of the format of base64 encoding, the end of the encoded block cannot always be reliably determined. that's just the truth of it, bestie 😭

---

🫶 RETURN VALUES 🫶

BIO_f_base64() returns the base64 BIO method. that's it, that's the whole thing ✨

---

🌟 EXAMPLES 🌟

Example one: base64 encode the string "Hello World\n" and write the result to standard output 💖

BIO *bio, *b64;
char message[] = "Hello World \n";

b64 = BIO_new(BIO_f_base64());
bio = BIO_new_fp(stdout, BIO_NOCLOSE);
BIO_push(b64, bio);
BIO_write(b64, message, strlen(message));
BIO_flush(b64);

BIO_free_all(b64);

Example two: read base64 encoded data from standard input and write the decoded data to standard output 🦋

BIO *bio, *b64, *bio_out;
char inbuf[512];
int inlen;

b64 = BIO_new(BIO_f_base64());
bio = BIO_new_fp(stdin, BIO_NOCLOSE);
bio_out = BIO_new_fp(stdout, BIO_NOCLOSE);
BIO_push(b64, bio);
while ((inlen = BIO_read(b64, inbuf, 512)) > 0)
    BIO_write(bio_out, inbuf, inlen);

BIO_flush(bio_out);
BIO_free_all(b64);

---

💀 BUGS 💀

okay so, the messy parts. brace yourself.

The hyphen character (-) is treated as an ad hoc soft end-of-input character when it occurs at the start of a base64 group of 4 encoded characters. it's giving "we made a rule and we're sticking to it" 🙈

This heuristic works to detect the ends of base64 blocks in PEM or multi-part MIME — provided there are no stray hyphens in the middle input. But it is just a heuristic, and sufficiently unusual input could produce unexpected results. so like, don't be weird with it 🫠

There should perhaps be some way of specifying a test that the BIO can perform to reliably determine EOF (for example a MIME boundary). someday maybe 💭

And — it may be possible for BIO_read(3) to return zero, rather than -1, even if an error has been detected. more tests are needed to cover all the potential error paths. lowkey a known gap, ngl.

---

👀 SEE ALSO 👀

• BIO_read(3)
• BIO_should_read(3)
• BIO_set_mem_eof_return(3)
• EVP_DecodeUpdate(3)

---

👑 COPYRIGHT 👑

Copyright 2000-2024 The OpenSSL Project Authors. All Rights Reserved.

Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <https://www.openssl.org/source/license.html>.

---

and that's the whole page, bestie 💜 this was OpenSSL 3.5.9, dated 2026-09-29 — so like, keep that in mind if you're reading a different version, periodt. mwah 🎀💖✨