Кодируйте и декодируйте Base64, Base64URL, процентное кодирование URL, HTML-сущности и hex прямо при вводе, с полной поддержкой UTF-8.
Ничего из введённого не сохраняется - данные преобразуются и возвращаются в том же запросе.
Токен в логе, строка запроса в редиректе, письмо, полное &: закодированный текст на работе встречается повсюду. Вставьте его сюда, выберите формат и смотрите результат кодирования или декодирования прямо при вводе.
JSON Web Token - это три части в Base64URL, разделённые точками: заголовок, полезная нагрузка и подпись. Вставьте среднюю часть, выберите Base64URL и декодируйте - вы увидите JSON-поля, например id пользователя и срок действия exp (Unix timestamp, который можно прочитать в конвертере Unix-времени). Декодирование - не проверка: полезную нагрузку JWT может прочитать любой, и только проверка подписи на сервере доказывает, что её не меняли.
Base64 без padding, который некоторые системы отбрасывают ради экономии места, не принимают строгие декодеры; этот инструмент добавляет недостающие знаки = и сообщает об этом. Многие серверы читают + в строке запроса как пробел, поэтому значение Base64, вставленное в ссылку без кодирования, приходит повреждённым; закодируйте его как компонент URL или используйте Base64URL. Дважды закодированный текст выглядит как %2520 или & и требует двойного декодирования.
Декодирование Base64 игнорирует пробелы и переносы строк, поэтому значение, разбитое на несколько строк, как в письме, декодируется прямо в том виде, в каком вставлено. Base64URL принимает также + и /, а обычный Base64 отклоняет - и _, поэтому часть JWT нужно декодировать в режиме Base64URL. Декодирование hex пропускает пробелы, двоеточия, запятые, дефисы и префиксы 0x, так что работают и 48:65:6c:6c:6f, и 0x48 0x65. Декодирование URL превращает + в пробел, поэтому настоящий знак плюс должен прийти как %2B. Кодирование HTML экранирует пять символов & < > " и '; декодирование HTML понимает все именованные сущности HTML5, например и …, и числовые, например ₹ для знака рупии.
URL-кодирование здесь кодирует одно значение, например один параметр запроса, поэтому экранируется каждый зарезервированный символ: https://example.com/a b?x=1&y=2 превращается в https%3A%2F%2Fexample.com%2Fa%20b%3Fx%3D1%26y%3D2. Кодируйте только значение, которое вставляете в ссылку, а не всю ссылку целиком. Текст вне ASCII кодируется своими байтами UTF-8: café ₹ превращается в caf%C3%A9%20%E2%82%B9, а hex показывает те же байты: é как c3 a9, ₹ как e2 82 b9. Base64 от user:pass равно dXNlcjpwYXNz, это значение передает заголовок HTTP Basic Authorization (RFC 7617), поэтому любой, кто видит этот заголовок, может прочитать пароль.
Байты были в UTF-8, но где-то до кодирования их прочитали как Latin-1 или Windows-1252. Здесь декодирование показывает байты как есть; исправлять нужно в системе, которая их создала.
Вставьте текст длиной до 200 000 символов. Для двоичных файлов, например изображений, декодированные байты показываются в hex, а не отдаются как файл для скачивания.
Нет. Base64 лишь меняет запись байтов, чтобы они проходили через системы, ожидающие обычный текст. Декодировать его может любой; никогда не используйте его, чтобы скрыть пароль или секрет.
Base64URL заменяет "+" и "/" на "-" и "_" и обычно убирает padding "=", поэтому результат безопасен в URL и именах файлов. Его используют JSON Web Tokens.
Нет. Он преобразуется и возвращается в том же запросе и никогда не записывается в базу данных или журнал.
Этот инструмент дополнительно экранирует ! ' ( ) и *, которые encodeURIComponent оставляет как есть, поэтому it's (50%) off! превращается в it%27s%20%2850%25%29%20off%21. Обе формы декодируются в один и тот же текст, а экранировать эти символы внутри значения параметра всегда безопасно. Пробел становится %20, а не +; форма с + пришла из кодирования HTML-форм, и декодер здесь понимает обе.
В Linux или Mac команда echo -n 'Hello, World' | base64 даёт SGVsbG8sIFdvcmxk, а echo 'SGVsbG8sIFdvcmxk' | base64 --decode возвращает исходный текст. Без -n echo добавляет перевод строки, который тоже кодируется, и получается SGVsbG8sIFdvcmxkCg==: самая частая причина, по которой два инструмента дают разный результат. В PowerShell [Convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes('Hello, World')) кодирует, а [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String('SGVsbG8sIFdvcmxk')) раскодирует. Эта страница кодирует ровно те символы, которые вы вставили, в UTF-8 и не добавляет перевод строки.
Вставьте только часть после запятой: в data:image/png;base64,iVBORw0KGgo... это iVBORw0KGgo..., потому что префикс data:image/png;base64, не является Base64 и вся строка будет отклонена. Выберите Base64 и Decode. Байты, которые не являются текстом, показываются в шестнадцатеричном виде, а не картинкой, но этого хватает, чтобы понять тип файла: PNG начинается с 89 50 4e 47, JPEG с ff d8 ff, а целый файл .docx, .xlsx или другой файл на основе ZIP с 50 4b 03 04. Чтобы увидеть само изображение, вставьте полный data URI в адресную строку браузера. Ввод ограничен 200 000 символов, это около 150 000 байт файла.
Base64 записывает каждые 3 байта четырьмя символами и дополняет последнюю группу знаками = до кратного 4 (RFC 4648), поэтому результат равен 4/3 входных байтов с округлением вверх. Hello, World занимает 12 байт и превращается в 16 символов SGVsbG8sIFdvcmxk. Считаются байты UTF-8, а не буквы: café это 4 символа, но 5 байт, и даёт Y2Fmw6k=, а ₹100 это 6 байт и даёт 4oK5MTAw. Вложения в письмах вырастают ещё немного, потому что MIME разбивает Base64 на строки не длиннее 76 символов (RFC 2045); эта страница при декодировании такие переносы строк пропускает. Base64URL без дополнения экономит только знаки =.