Почему Base64 делает файлы больше?

Эта статья объясняет, почему выход Base64 больше исходных байтов. Это не руководство по безопасности. Если нужно кодирование против шифрования, используйте Base64 — это не шифрование: что оно делает и как декодировать.

Почему Base64 нужно больше места?

3 байта — это 24 бита. Base64 делит эти 24 бита на 4 группы по 6 бит. Каждая группа становится одним символом Base64, поэтому 3 входных байта становятся 4 выходными символами. В хранении по 1 байту на символ ASCII это 4 / 3 ≈ 1.333 — прирост около 33.3%.

• 3 байта (24 бита)
• ↓
• Разделить на 4 группы по 6 бит
• Каждая группа → один символ Base64
• ↓
• 4 символа (часто 4 байта текста)

Простой проверяемый пример

Эти кодировки совпадают со стандартным Base64 с дополнением.

Man

Man

Base64

TWFu

Man — 3 байта UTF-8/ASCII. TWFu — 4 символа: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello — 5 байтов. SGVsbG8= — 8 символов, включая один =. На малых данных дополнение делает процент внешне больше 33%.

Как посчитать размер Base64?

Для стандартного Base64 с дополнением encodedLength = 4 × ceil(originalBytes / 3).

Исходные байты	Символы Base64
1	4
2	4
3	4
4	8
5	8
6	8

1 или 2 байта всё равно дают 4 символа. Берите формулу, а не фиксированные 33%.

Что означает дополнение «=»?

Знак = показывает, что последний блок из 3 байтов был неполным. 1 входной байт использует два символа =; 2 байта — один; 3 байта — ни одного. Дополнение — не шифрование и не функция безопасности.

Занимает ли Base64URL меньше места?

Base64URL меняет + на - и / на _, а Кодировать Base64 при кодировании опускает конечные =. Это может укоротить строку на эти символы =. Структура 3 байта → 4 символа сохраняется, поэтому Base64URL — не более экономный двоичный формат.

Почему крошечные входы могут вырасти больше чем на 33%?

1 байт → 4 символа — это прирост длины 300%. 2 байта → 4 — это 100%. 3 байта → 4 — около 33.3%. По мере роста n дополнение значит меньше, и лишний размер приближается к примерно 33%. Base64 не на 33% больше в каждом случае.

Почему Data URL с Base64 ещё больше?

Data URL добавляет префикс вроде data:image/png;base64, перед нагрузкой. На крошечном файле этот префикс может доминировать в проценте. Кодировать Base64 может выдать сырой Base64 или Data URL; вывод Data URL использует стандартный алфавит.

Base64 против двоичных данных: что меньше?

Сырые двоичные данные экономнее по месту для передачи и хранения. Base64 больше, но безопасен как текст в JSON, почте и других только текстовых путях. Это кодирование из двоичного в текст, не сжатие.

Сжимает ли Base64 файлы?

Нет. Base64 — не формат сжатия. Закодированный текст обычно больше исходных байтов. Если потом применить gzip или Brotli к этому тексту, часть избыточности может сжаться — результат зависит от данных и компрессора. gzip не убирает полностью лишний размер Base64.

Что будет, если к Base64 применить gzip?

HTTP-сжатие может уменьшить некоторые повторяющиеся шаблоны в тексте Base64. JPEG, PNG или ZIP часто сжимаются плохо даже как сырые байты, и Base64-затем-gzip по-прежнему зависит от случая. Универсального лишнего процента после gzip нет.

Стоит ли хранить файлы как Base64?

Base64 может уместить двоичные данные в поле JSON, маленький встроенный ресурс, текстовый API, копирование/вставку или Data URL. Для больших файлов растут хранение, память и размер нагрузки. Это не «никогда не используйте Base64 для файлов».

Почему Base64 обычен в JSON API?

У JSON нет встроенного типа сырых двоичных данных, поэтому API часто кладут байты в строку Base64. Для больших файлов лучше могут подойти multipart/form-data, объектное хранилище или прямая двоичная загрузка. Никакой выбор не всегда лучший.

Почему Base64 используют в почте?

MIME может использовать Base64, чтобы двоичное вложение шло как символы, безопасные для текста. Тот же лишний размер всё равно действует. Это транспортное представление, не меньший файл.

Когда лишний размер оправдан?

Лишний размер может быть оправдан, когда двоичные данные должны жить внутри текста, нагрузка мала, API требует Base64 или нужна Data URL. Для больших медиа предпочитайте сырые двоичные данные, если система это позволяет.

Когда лучше избегать Base64?

Пропускайте его для больших файлов, узкой полосы, частых передач или когда двоичный путь уже есть — по ситуации, не «Base64 — плохая практика».

Длины Base64 с дополнением, которые можно проверить

Числа исходных байтов и числа символов стандартного Base64 с дополнением:

Исходные байты	Символы Base64
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Все строки следуют 4 × ceil(n / 3). Это числа символов Base64.

Пример: каким станет файл на 1,000 байт?

4 × ceil(1000 / 3). ceil(333.333…) = 334, и 4 × 334 = 1336. Итого 1,000 байт становятся 1,336 символами Base64. В UTF-8/ASCII каждый символ обычно 1 байт — не считайте 1,336 точным числом байтов в памяти.

Может ли Base64 занимать больше памяти, чем намекает размер файла?

Некоторые среды хранят строки больше чем по 1 байту на символ, а кодирование/декодирование может держать буфер и строку одновременно. Использование памяти не равно в точности длине в символах.

Простое руководство по решению о размере

Если система принимает сырые двоичные данные, предпочитайте их ради размера. Если разрешён только текст, Base64 может подойти. Для большой нагрузки ищите путь двоичной загрузки. Для текста, безопасного в URL, рассмотрите Base64URL — расширение 3 к 4 остаётся.

• Нужно отправить двоичные данные
• ↓
• Сырые двоичные данные разрешены? Предпочесть двоичные ради размера
• Только текстовое поле? Base64 может подойти
• Большая нагрузка? Искать путь двоичной загрузки
• Нужен текст, безопасный для URL? Рассмотреть Base64URL
• ↓
• На больших входах ожидать примерно на 33% больше текста

Кодируйте или декодируйте Base64 в браузере

NEXNARA Кодировать Base64 кодирует и декодирует текст и может превратить файл в Base64 или Data URL и вернуть Base64 обратно в файл.

Текст идёт байтами UTF-8, затем Base64 — не только ASCII. Выберите Standard или Base64URL. Выход файла может быть сырым Base64 или Data URL (стандартный алфавит). Неверный ввод отклоняется. Байты не UTF-8 нужно отправлять в файл, а не в текстовое декодирование.

Файлы больше 10 MB могут замедлить вкладку (предупреждение). Файлы больше 32 MB блокируются.

Кодирование и декодирование происходят в вашем браузере. Файл не отправляется на сервер NEXNARA для этого инструмента. Реклама и другие функции сайта по-прежнему используют сеть.

Вставьте текст или файл в Кодировать Base64 и сравните исходные байты с длиной после кодирования.

FAQ

Почему Base64 увеличивает размер файла?

Оно отображает 3 байта (24 бита) в 4 символа (4 × 6 бит). В виде текста это примерно на треть больше для больших входов.

Base64 всегда на 33% больше?

Нет. Большие входы приближаются к примерно 33.3%. Крошечные входы могут вырасти сильнее из‑за дополнения. Используйте 4 × ceil(n / 3).

Насколько Base64 больше двоичных данных?

Стандартная длина с дополнением — 4 × ceil(n / 3) символов. Префикс Data URL добавляет ещё.

Сжатие Base64 уменьшает размер файла?

Base64 не сжимает. gzip или Brotli по закодированному тексту могут ужать часть; они не стирают лишний размер в каждом случае.

Занимает ли Base64URL меньше места?

Оно может опустить дополнение =, поэтому строка может быть короче на 0–2 символа. Структура кодирования 3 к 4 та же.

Стоит ли использовать Base64 для больших файлов?

Только если нужен текст. Для больших или частых передач двоичный путь часто меньше. Base64 не всегда неверен для API.