Base64 кодирование/декодирование
Кодирование/декодирование Base64 поддерживает сценарии для текста и изображений. Вы можете кодировать и декодировать текст, преобразовывать изображения в Data URL или raw Base64, а также обратно превращать Data URL / Base64 в изображения с локальным предпросмотром и скачиванием.
Входной текст
Символ
0 / 500,000
Выберите или перетащите изображение
Поддерживаются PNG, JPEG, WebP, GIF, SVG, BMP, AVIF, TIFF, ICO, HEIC и HEIF, если браузер умеет их читать.
Выходной текст
Выходной текст
Входной текст
Символ
0 / 500,000
MIME-тип для raw Base64
Raw Base64 не содержит информации MIME. Сначала выберите исходный тип изображения, чтобы предпросмотр мог быть создан автоматически.
Вставьте Data URL изображения или raw Base64 и выберите MIME-тип, чтобы увидеть предпросмотр здесь.
Быстрый старт
Частые сценарии
URL/JWT
предпочтительно использовать вариант URL‑safe (−/_); завершающий '=' можно опустить, чтобы избежать экранирования
Почта/MIME
при необходимости переноса используйте правило 76 символов (CRLF); для веба переносы обычно не нужны. Инструмент поддерживает перенос на 76 символов и переключатель LF/CRLF
Многострочный текст
включите построчное кодирование для независимой обработки строк
MIME/PEM
включите перенос 76; при необходимости включите LF
Data URL
при встраивании генерируйте data:[mime];base64,…; декодер автоматически берёт часть после запятой
Проверка туда‑обратно
сразу после кодирования выполните декодирование и сравните
Загрузка изображения
сохраняйте исходные байты и переключайтесь между Data URL и raw Base64 без повторной загрузки.
Data URL изображения
вставьте data:image/...;base64,..., чтобы автоматически определить MIME-тип и сразу показать изображение.
Raw Base64-данные изображения
укажите исходный MIME-тип изображения, чтобы инструмент мог автоматически показать предпросмотр и скачать его как изображение.
Параметры кодирования и варианты
Рекомендации по использованию
Ограничения и совместимость
Конфиденциальность и безопасность
Частые вопросы
Base64 — это схема представления произвольных двоичных данных печатными текстовыми символами. Появилась в почтовом стандарте MIME (1990‑е, RFC 1521/2045), позднее унифицирована RFC 4648. Цель — не «шифрование», а надёжная передача байтов по текстовым каналам. Как это работает: каждые 3 байта (24 бита) разбиваются на четыре 6‑битовых блока и отображаются на 64 символа A–Z, a–z, 0–9, +, /. Если длина не кратна 3, для выравнивания используется «=». Размер обычно увеличивается на ~33 %. Варианты и выбор: RFC 4648 определяет вариант URL‑safe (символы «-» и «_» вместо «+» и «/»; конечные «=» можно опускать). Для URL/Cookie/JWT лучше URL‑safe; для устаревших/MIME‑инструментов — стандартный Base64 (с +/ и =). Этот инструмент по умолчанию выдаёт URL‑safe; декодер принимает оба варианта. Примеры: ??? → стандартный Pz8/, URL‑safe Pz8_; ~~~ → стандартный fn5+, URL‑safe fn5‑. Data URL: при встраивании используйте data:[mime];base64,…; при декодировании извлекайте часть после запятой (инструмент делает это автоматически). Вехи (кратко): 1993 RFC 1521 (MIME v1, Ned Freed & Nathaniel Borenstein) → 1996 RFC 2045 (обновление MIME) → 2003 RFC 3548 (Simon Josefsson, абстракция Base16/32/64) → 2006 RFC 4648 (Simon Josefsson, унификация и Base64URL, замещает 3548). Также: 1993 RFC 1421 (PEM, J. Linn) использует Radix‑64 (родственно Base64) для переноса двоичных данных в письмах. Безопасность: Base64 — обратимое форматирование, не даёт конфиденциальности/целостности; сначала шифруйте, затем кодируйте.
Нет. Любой может декодировать. Для конфиденциальности сначала шифруйте
Строка должна содержать только A–Z, a–z, 0–9, +, / и =, а также иметь корректную длину
Различия обычно связаны с переносами строк, сохранением или удалением заполнителя '=', вариантом URL-safe (-/_), либо с разной текстовой кодировкой. При сравнении результатов убедитесь, что с обеих сторон используется одна и та же кодировка текста, отключён автоматический перенос и согласовано использование URL-safe и заполнителя.
Base64 представляет 8 бит через 6 бит; прирост ~33% — свойство метода
Да. Эмодзи и многоязычный текст в текстовом режиме обрабатываются как UTF-8. Если результат декодирования на самом деле является нетекстовыми двоичными данными, нечитаемый вывод — это нормально.