Кодировщик/Декодировщик Base64
Быстрое кодирование и декодирование Base64 с поддержкой UTF-8 текста
Выберите способ конвертации
Что такое Base64?
Base64 — это метод использования 64 печатных символов для представления двоичных данных. Эти 64 символа включают заглавные буквы A-Z, строчные a-z, цифры 0-9 и два символа + и /. Поскольку используются только печатные символы, данные в кодировке Base64 можно безопасно передавать в средах, поддерживающих только текст, таких как электронная почта, веб-страницы и JSON. Закодированные данные увеличиваются примерно на 33% по сравнению с исходными. Base64 впервые появился в 1987 году в протоколе PEM для безопасной передачи двоичных данных в электронной почте. Сегодня это один из интернет-стандартов, широко используемый в различных сценариях: от вложений электронной почты до токенов JWT, от встраивания изображений до передачи данных. Почти во всех языках программирования есть встроенные функции кодирования и декодирования Base64.
Как использовать
Как использовать
- Вставьте текст в левое поле ввода
- Выберите операцию «Кодировать» или «Декодировать»
- Результаты автоматически появятся справа
- Нажмите кнопку копирования, чтобы сохранить результат
Распространённые ошибки
- Base64 — это кодирование, а не шифрование: любой, у кого есть текст, может его декодировать, поэтому не используйте его для защиты секретов.
- Если декодирование не удаётся, проверьте наличие символов дополнения, лишних переносов строк, символов URL-safe Base64 или обрамляющих кавычек.
Применение
Технический принцип
Base64 — одна из нескольких кодировок «бинарные данные → текст», определённых в RFC 4648 (S. Josefsson, октябрь 2006), наряду с Base16 (hex) и Base32. Название и алфавит 'Base64' изначально были определены для Privacy-Enhanced Mail (RFC 989, 1987), где PEM оборачивал бинарные S/MIME и X.509 материалы в печатный ASCII-конверт, чтобы они могли передаваться через 7-битные транспорты. Тот же алфавит позднее стал де-факто стандартом для MIME (RFC 2045), подписей JWT (RFC 7519), data: URI в HTML (RFC 2397), публичных ключей SSH (RFC 4253 §6.6) и файлов-указателей Git LFS (которые хранят SHA-256 хеши в Base64). Собственные pack-файлы Git НЕ используют Base64 — они используют дельта-кодирование с zlib-сжатием, а идентификаторы объектов Git — это 40-символьные hex-строки SHA-1, а не Base64. Стоимость: каждые 3 входных байта превращаются в 4 выходных символа, поэтому закодированный выход ровно в 4/3 раза больше (33,3% накладных расходов). Для 10 МБ бинарных данных закодированная форма составит ~13,3 МБ. Механизм: входные данные разбиваются на группы по 3 байта (24 бита); каждая группа делится на четыре 6-битных значения; каждое 6-битное значение выбирает один символ из 64-символьного алфавита. Канонический алфавит: A-Z (индексы 0-25), a-z (26-51), 0-9 (52-61), '+' (62), '/' (63), с '=' как символом заполнения. Классический пример из RFC 4648: 'Man' (0x4d 0x61 0x6e) упаковывается в 24-битное значение 0x4d616e; разделение на 6-битные фрагменты даёт 0x0d 0x16 0x0e 0x0a, что соответствует 'TWFu'. Когда длина входных данных не кратна 3, последняя группа дополняется нулями справа: остался 1 байт → 2 значимых 6-битных фрагмента + '==' (2 символа заполнения); осталось 2 байта → 3 значимых фрагмента + '=' (1 символ заполнения). Символы заполнения не несут информации, но делают длину кодирования детерминированной функцией от длины входных данных и позволяют декодерам отвергать обрезанный ввод. В браузере у Base64 есть два печально известных подводных камня. Во-первых, `btoa` и `atob` (варианты DOMString) работают с кодовыми единицами Latin-1, а не с байтами — передача строки, содержащей U+00E9 (é) или U+4E2D (中), вызывает InvalidCharacterError. Страница обходит это, пропуская данные через `TextEncoder().encode(str)` (всегда UTF-8) перед вызовом `btoa`, и `TextDecoder().decode(bytes)` после `atob`. Многобайтовые символы UTF-8 расширяются: '你' — это 3 байта (0xe4 0xbd 0xa0) → 4 символа base64 (8 символов base64 для '你好'). Во-вторых, Base64URL (RFC 4648 §5) заменяет '+' и '/' на '-' и '_' и убирает заполнение, потому что '+' и '/' значимы в URL, а '=' завершает строки запроса. JWT (RFC 7519) и JWS (RFC 7515) требуют Base64URL именно по этой причине. Base64 — это кодирование, а не шифрование; закодированная форма не имеет никакой секретности, а алфавит настолько короткий, что любой наблюдатель читает результат элементарно. Ошибочное принятие Base64 за механизм безопасности — это устойчивый паттерн CVE: CVE-2004-2761 документирует коллизию X.509 MD5 с выбранным префиксом, позволявшую злоумышленникам подделывать сертификаты с коллизионными MD5-подписями, а CVE-2005-4900 и другие связаны со старой практикой, когда хеши паролей `$1$` md5crypt повторно кодировались или повторно хешировались аутентификационным слоем, путающим Base64-декодированные байты с новыми учётными данными. Повторяющийся паттерн один и тот же: система treats кодирование как добавляющее слой секретности, которого оно не даёт, и результат становится эксплуатируемым. Для реальных секретов используйте AES-GCM (RFC 5288) или ChaCha20-Poly1305 (RFC 8439). Для сжатия-затем-Base64 (что делает `gzip -b64`), учтите, что закодированная форма примерно в 1,37 раза больше сжатого размера, и любое изменение байта в сжатом потоке ломает декодирование — поэтому Base64 плохо подходит как слой целостности; HMAC-SHA256 по байтам перед кодированием — правильный подход.
- RFC 4648 (октябрь 2006) определяет Base64, Base32 и Base16 с одним каноническим алфавитом (A-Z, a-z, 0-9, +, /) и '=' как символом заполнения. Вариант MIME (RFC 2045) вставляет переносы строк каждые 76 символов для транспорта; URL-безопасный вариант (Base64URL, RFC 4648 §5) заменяет + и / на - и _ и убирает заполнение — используется в JWT (RFC 7519), JWS (RFC 7515) и JWK (RFC 7517).
- Механизм: 3 входных байта (24 бита) → 4 выходных символа (каждый по 6 бит). Накладные расходы — 33,3%: каждый 1 МБ бинарных данных превращается в 1,33 МБ Base64. Для ASCII соотношение может быть ещё хуже, если входные данные содержат '=' или другие символы, экранируемые окружающими протоколами.
- Правило заполнения: длина входных данных mod 3 = 0 → без заполнения; mod 3 = 1 → '==' (два символа заполнения, один закодированный байт); mod 3 = 2 → '=' (один символ заполнения, два закодированных байта). '=' не несёт информации; он лишь позволяет декодеру узнать, сколько байтов было отброшено.
- Подводный камень UTF-8 + btoa: `btoa('é')` вызывает InvalidCharacterError, потому что btoa воспринимает ввод как кодовые единицы Latin-1. Страница обходит это, кодируя через `TextEncoder` (UTF-8) перед btoa и декодируя через `TextDecoder` после atob. Без этого шага всё вне диапазона U+0000..U+00FF превращается в '0 закодированных байтов' вместо ошибки.
- Base64URL требуется для JWT, JWS и JWK (RFC 7519/7515/7517). Он использует '-' и '_' вместо '+' и '/' (URL-значимые символы) и убирает заполнение '=' (которое завершает строки запроса). Передача сегмента заголовка JWT декодеру Base64 вместо Base64URL возвращает мусор; страница не автоопределяет — выбирайте правильный вариант для полезной нагрузки.
- Производительность: кодирование примерно 400-700 МБ/с в V8 на современном ноутбуке (компактный цикл с поиском таблицы и битовыми сдвигами). Декодирование работает с аналогичной скоростью. Для больших данных (10+ МБ) узкое место — выделение памяти, а не вычисления: выходной буфер на 33% больше, а `TextEncoder/TextDecoder` делает копию.
- Base64 — это кодирование, а не шифрование: любой, у кого есть строка, может её прочитать. CVE-2004-2761 (коллизия X.509 MD5 с выбранным префиксом на подписях сертификатов) и множество статей CTF используют это заблуждение как первую ступеньку. Для секретов используйте AES-GCM (RFC 5288) или ChaCha20-Poly1305 (RFC 8439). Для data: URI следите за закодированным размером: 10 МБ изображение превращается в 13,3 МБ URL, что превышает лимит длины URL большинства браузеров и лимит размера большинства почтовых сервисов.
- Замечание по миграции: Base16 (hex) предпочтителен в низкоуровневых протоколах и на выходе хеш-функций, поскольку каждый байт отображается ровно в 2 символа и длина предсказуема (без математики заполнения). Base32 предпочтителен для ручной транскрипции (нет похожих символов). Base64 — универсальный по умолчанию для бинарной передачи в текстовых протоколах, но постепенно заменяется сырыми байтами через HTTP/2 и WebTransport, где фреймирование это позволяет.
Примеры
Кодирование ASCII-текста
Вход: Hello
Выход: SGVsbG8= (5 байт -> 8 символов, 1 символ дополнения)
Вход: Hello, World!
Выход: SGVsbG8sIFdvcmxkIQ== (13 байт -> 18 символов, 1 символ дополнения)
Вход: Man
Выход: TWFu (3 байта -> 4 символа, без дополнения)
Пример 'Man' — канонический вектор RFC 4648: байты 0x4D 0x61 0x6E
упаковываются в 24-битное значение 0x4D616E, разбиваются на 6-битные
фрагменты 0x0D 0x16 0x0E 0x0A и отображаются в T W F u по стандартному алфавиту.Кодирование UTF-8 текста (Китайский)
Вход: ni hao (3 байта ASCII)
Выход: 5L2g5aW9 (8 символов)
Вход: ni hao shi jie (4 CJK-символа, 12 байт UTF-8)
Выход: 5L2g5aW95LiW55WM (16 символов)
Каждый CJK-символ занимает 3 байта UTF-8 (E4 BD A0 и т. д.), поэтому
выход Base64 увеличивается ~4/3, а затем ~4/3 ещё раз — примерно в
2,67 раза больше количества символов в выводе. Страница сначала
пропускает данные через TextEncoder().encode(str), чтобы избежать
ошибки btoa('InvalidCharacterError') на не-ASCII входе.Декодирование и round-trip сегмента JWT
Закодировано: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Декодировано: {"alg":"HS256","typ":"JWT"}
Round-trip:
encode('{"alg":"HS256","typ":"JWT"}') -> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
decode('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9') -> {"alg":"HS256","typ":"JWT"}
Сегменты JWT используют Base64URL, поэтому страница должна принимать
'-' / '_' наряду со стандартными '+' / '/'. Заголовок JWT, поданный
строгому декодеру Base64, вернёт мусор — выберите правильный вариант
под данные.Base64 vs Base64URL
Вход: Hello><h2>
Стандартный: SGVsbG8+PGgyPg== (+ / = дополнение; безопасно внутри JSON / email)
URL-safe: SGVsbG8-PGIyPg (- _ без дополнения; безопасно в URL-путях/запросах)
Различия:
'+' (62) -> '-' и '/' (63) -> '_'
'=' дополнение полностью убрано в URL-safe форме
Используйте Base64URL для JWT, JWS, JWK и любых токенов, передаваемых
в query-строке URL, потому что '+' / '/' значимы в URL, а '='
завершает запрос.Часто задаваемые вопросы
Base64 — это шифрование?
Нет. Base64 — это кодирование, а не шифрование. Он лишь превращает произвольные байты в 64 печатаемых ASCII-символа (A–Z, a–z, 0–9, +, /), чтобы они спокойно проходили через системы, которые портят бинарные данные. Любой человек со закодированной строкой мгновенно её расшифрует — никакого секрета здесь нет.
Почему мой закодированный вывод заканчивается одним или двумя знаками =?
Base64 выдаёт 4 выходных символа на каждые 3 входных байта. Когда длина входа не кратна трём, кодировщик дополняет результат знаками =, чтобы длина оставалась кратной четырём. Один лишний входной байт — две =; два лишних байта — одна =; ровный вход — без них. Некоторые реализации опускают дополнение, что допустимо стандартом, но совместимо не везде.
Что такое URL-safe Base64?
Стандартный Base64 содержит / и +, у которых в URL и именах файлов особое значение. URL-safe Base64 (RFC 4648 §5) заменяет их на _ и - и часто отбрасывает дополнение =. Используйте его для JWT, параметров URL и имён файлов; во всех остальных местах применяйте обычный Base64.
Почему Base64-строка примерно на 33 % длиннее исходных данных?
Каждые 6 бит входа становятся одним 8-битным выходным символом, поэтому размер закодированных данных = ceil(input_length / 3) * 4. Это примерно 4/3 от входа (накладные расходы около 33 %). Такова цена представления произвольных байтов в печатаемом ASCII.
Какие данные можно сюда вставлять?
Для кодирования вставляйте обычный текст (под капотом он пойдёт в UTF-8) или загружайте файл. Для декодирования вставляйте Base64-строку с пробелами или без — декодер сам уберёт переносы строк. Если декодирование падает, проверьте лишние символы или пропущенный знак =.
Может ли Base64 переносить содержимое бинарных файлов?
Да, это его основное применение — встроенные картинки в HTML/CSS (data: URL), вложения в email (MIME), учётные данные в HTTP-заголовках (Basic Auth) — везде Base64 используется, чтобы протолкнуть бинарные данные через текстовые каналы. Учитывайте, что итоговая нагрузка на 33 % больше исходного файла.
Можно ли использовать Base64, чтобы спрятать чувствительные данные?
Никогда. Base64 полностью обратим без какого-либо ключа, и считать его обфускацией — распространённая ошибка, которая в реальных инцидентах уже многократно приводила к утечкам паролей и токенов. Для всего чувствительного используйте нормальное шифрование или менеджер секретов.