QuickATools

Narzędzia deweloperskie · Free browser tool

Kodowanie/dekodowanie Base64

Koduj tekst do formatu Base64 lub dekoduj stringi Base64 z powrotem na tekst natychmiast — pełne wsparcie UTF-8 i zero wycieku danych.

Plain text

Any text, including emoji and non-Latin scripts.

0 chars0 bytes (UTF-8)

Base64 result

Your Base64 result will appear here.

0 chars0 bytes (UTF-8)

Frequently Asked Questions

Do czego właściwie służy kodowanie Base64?

Base64 zamienia dowolne dane binarne (lub tekst) na string złożony wyłącznie z liter, cyfr, +, / i = — znaków bezpiecznych do osadzenia w miejscach zaprojektowanych pod zwykły tekst, jak pola JSON, URL-e, załączniki e-mail, nagłówki HTTP czy pliki konfiguracyjne. To nie jest szyfrowanie ani kompresja; to czysto bezpieczny format transportu i każdy może go od razu zdekodować z powrotem do oryginału.

Dlaczego kodowanie tekstu koreańskiego lub emoji zwykłym btoa()/atob() psuje wynik albo rzuca błąd?

Wbudowana funkcja btoa() przeglądarki przyjmuje tylko znaki z zakresu bajtów 0–255 (Latin-1). Znaki koreańskie, emoji i większość skryptów innych niż łacińskie używają wielobajtowych sekwencji UTF-8 poza tym zakresem, więc btoa() albo rzuca „InvalidCharacterError”, albo po cichu psuje tekst. To narzędzie omija to całkowicie: najpierw zamienia tekst na surowe bajty UTF-8 przez TextEncoder, koduje te bajty do Base64 i odwraca te same kroki przy dekodowaniu przez TextDecoder — więc koreański, emoji i znaki z akcentami wracają idealnie.

Co oznaczają znaki paddingu „=” na końcu stringa Base64?

Base64 koduje dane w kawałkach po 3 bajty, które stają się 4 znakami wyjścia. Gdy oryginalne dane nie są czystą wielokrotnością 3 bajtów, na końcu dodawane są znaki „=”, żeby dopełnić ostatnią grupę do 4 znaków — jeden „=”, jeśli zostały 2 bajty, dwa „=”, jeśli został 1 bajt. Ich obecność (lub brak) to normalna, oczekiwana część poprawnego Base64 — nie błąd.

Czy bezpiecznie dekodować klucze API lub hasła w online’owym narzędziu Base64?

To zależy wyłącznie od tego, czy narzędzie wysyła input na serwer. To narzędzie nigdy tego nie robi — każda konwersja działa lokalnie w przeglądarce przez wbudowane API JavaScript (TextEncoder, TextDecoder, btoa, atob), bez żadnego żądania sieciowego. Dlatego bezpiecznie możesz dekodować wrażliwe wartości jak klucze API, segmenty JWT albo nagłówki Basic Auth, których nigdy nie powinieneś wklejać do narzędzia proxy’ującego input przez backend, którego nie kontrolujesz.

Dlaczego Base64 to nie szyfrowanie — i dlaczego to ma znaczenie dla bezpieczeństwa

Base64 to format transportu, nie środek bezpieczeństwa. Każdy może zdekodować string Base64 z powrotem do oryginału jednym kliknięciem — nie ma tu tajnego klucza. Prawdziwe pytanie o bezpieczeństwo nie brzmi „czy to jest zakodowane”, tylko „gdzie trafiają moje dane, gdy je dekoduję lub koduję?” Zaskakująco wiele konwerterów online po cichu wysyła to, co wkleisz, na własny serwer do przetworzenia — a to realny problem, gdy dekodujesz klucz API, payload JWT albo nagłówek Basic Auth wyciągnięty z logów produkcyjnych.

To narzędzie nigdy tego nie robi. Każda konwersja — kodowanie lub dekodowanie — idzie przez własne API TextEncoder, TextDecoder, btoa i atob przeglądarki, bez żadnego żądania sieciowego. Możesz bezpiecznie zdekodować podejrzany token lub zweryfikować poświadczenie, nie opuszczając maszyny.

Obsługa UTF-8 ma znaczenie równie duże jak historia prywatności. Gołe wywołanie btoa() psuje się w chwili, gdy tekst zawiera koreański, japoński, emoji lub łacinę z akcentami, bo rozumie tylko zakres bajtów Latin-1. To narzędzie prowadzi wszystko najpierw przez poprawne kodowanie bajtów UTF-8, więc znaki wielobajtowe zawsze wracają poprawnie — zakoduj string z emoji, zdekoduj z powrotem i dostaniesz dokładnie to samo emoji, a nie zniekształcony znak zastępczy.

Pracujesz dalej ze strukturą danych? Połącz to z formatterem i walidatorem JSON, żeby uporządkować odpowiedź API po zdekodowaniu. Kolejne narzędzia dla deweloperów — w tym generator UUID — pojawią się w tej kategorii.