Кодировщик/декодировщик Base64

Кодировщик/декодировщик Base64

Base64 — это способ представления произвольных двоичных данных с помощью всего 64 печатаемых ASCII-символов (A-Z, a-z, 0-9, +, /), благодаря чему они переживают передачу через системы, надёжно работающие только с текстом — email (вложения MIME), URL (data:-URI, встраивающие изображение прямо в HTML или CSS), HTTP-заголовки (схема авторизации «Basic» кодирует «user:password» именно так) и сегменты header/payload в JWT. Каждые 3 исходных байта превращаются в 4 символа Base64, поэтому закодированная строка всегда примерно на треть длиннее исходной; завершающий «=» или «==» дополняет вывод, если длина входа не кратна 3.

Встроенные функции браузера для этого, btoa() и atob(), понимают только Latin-1 (однобайтовые) символы — вызов btoa() напрямую со строкой, содержащей «café» или «日本語», выбрасывает исключение, что становится частой ловушкой для тех, кто впопыхах тянется к Base64. Этот инструмент полностью избегает такой проблемы: при кодировании ваш текст сначала превращается в представление UTF-8 (через TextEncoder), а уже эти байты кодируются в Base64; при декодировании происходит обратное (TextDecoder, отклоняющий всё, что не является корректным UTF-8, вместо того чтобы молча выдать искажённые символы). Это означает полную поддержку round-trip для любого Unicode-текста, а не только простого ASCII.

Декодирование корректно завершается ошибкой в двух разных случаях, и этот инструмент указывает, какой именно произошёл: либо вход вообще не является корректным Base64 (неверная длина или символ вне стандартного алфавита — проверяется до попытки декодирования), либо это синтаксически верный Base64, который декодируется в байты, не являющиеся корректным UTF-8-текстом (например, Base64 изображения JPEG или подписи JWT — это сырые двоичные данные, а не текст). Второй случай ожидаем и не является ошибкой инструмента — эти байты изначально не предназначались для чтения как текст.

Один важный вариант, который этот инструмент НЕ использует напрямую: Base64URL — алфавит, безопасный для URL и файловых систем, заменяющий «+» и «/» на «-» и «_» и отбрасывающий дополнение — используется в JWT и некоторых потоках OAuth именно потому, что символы «+» и «/» стандартного Base64 имеют особое значение в URL. Если вы пытаетесь декодировать сегмент header или payload JWT, используйте специализированный декодер JWT — он автоматически применяет преобразование Base64URL в Base64 за вас.

Глоссарий

Base64

Схема кодирования, представляющая двоичные данные с помощью 64 печатаемых ASCII-символов, благодаря чему они переживают передачу через текстовые каналы вроде email или URL.

MIME

Multipurpose Internet Mail Extensions — стандарт, определяющий, как email-сообщения несут не-текстовое содержимое (вложения, изображения), обычно закодированное в Base64.

UTF-8

Доминирующая кодировка Unicode-текста с переменной длиной байт — именно её этот инструмент использует, чтобы превратить ваш текст в байты перед Base64-кодированием.

Символ дополнения (=)

Один или два завершающих символа «=», дополняющие Base64-строку до длины, кратной 4 символам, если длина входа не кратна 3 байтам.

Base64URL

Безопасный для URL и файловых систем вариант Base64 (RFC 4648 §5), заменяющий «+»/«/» на «-»/«_» и отбрасывающий дополнение — используется в JWT и некоторых OAuth-токенах.

data:-URI

Схема URL, встраивающая содержимое ресурса прямо инлайн (например, «data:image/png;base64,...») вместо ссылки на него — обычно используется для встраивания небольших изображений в HTML или CSS.

API-эквивалент

У этого инструмента нет API-эквивалента в нашем сервисе — кодирование Base64 не является фактом об IP-адресе, поэтому нашему API здесь нечего возвращать. Преобразование выше выполняется полностью на вашем устройстве; ничего никуда не отправляется. Если вы искали наш API для поиска по IP — он покрывает геолокацию, ASN/сеть и данные об угрозах/мошенничестве для IP-адреса:

Читать полную документацию API

Похожие инструменты

• Все инструменты для разработчиков
• Декодер JWT
• Генератор хешей (MD5/SHA-1/SHA-256)

Часто задаваемые вопросы

Для чего используется кодирование Base64?

Для передачи двоичных или не-ASCII данных через каналы, которые надёжно работают только с обычным текстом — вложения email (MIME), data:-URI, встраивающие изображения в HTML/CSS, заголовки HTTP Basic Authorization и сегменты header/payload в JWT.

Шифрует ли Base64 или защищает ли мои данные?

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

Почему декодирование завершилось ошибкой?

Либо текст вообще не является корректным Base64 (неверная длина или символы вне A-Z a-z 0-9 + / =), либо это корректный Base64, который декодируется в байты, не являющиеся корректным UTF-8-текстом — например, Base64 изображения или двоичной подписи JWT, которые изначально не предназначались для отображения как текст.

Поддерживает ли этот инструмент Unicode, а не только английский текст?

Да — перед кодированием ваш текст преобразуется в байты UTF-8 (и проверяется как UTF-8 при декодировании), поэтому буквы с диакритикой, кириллица, иероглифы CJK и эмодзи корректно проходят round-trip — в отличие от «сырых» функций браузера btoa()/atob(), которые выбрасывают ошибку на всём, что выходит за пределы Latin-1.

Отправляется ли мой текст на сервер?

Нет — всё преобразование выполняется в вашем браузере встроенными функциями JavaScript. Эта страница не делает ни одного сетевого запроса для этого.

В чём разница между стандартным Base64 и Base64URL?

Base64URL (RFC 4648 §5) заменяет символы «+» и «/» на «-» и «_» и отбрасывает дополнение, потому что «+» и «/» имеют особое значение внутри URL. JWT используют Base64URL, а не стандартный Base64 — для них используйте инструмент декодера JWT, а не эту страницу.