Rozmiar Base64
Policz narzut Base64: ile bajtów zajmie ciąg po zakodowaniu albo ile danych kryje się za daną długością Base64. Encoding, nie kompresja — wynik po Oblicz.
Wynik
Wprowadź dane i kliknij Oblicz.
Co oznacza rozmiar Base64 w praktyce
Base64 zamienia bajty na tekst ASCII bezpieczny w JSON, XML, e-mailu i data-URI. To kodowanie transportowe, nie kompresja: po zakodowaniu ciąg zwykle zajmuje więcej miejsca niż oryginał.
Ten kalkulator odpowiada na dwa pytania: „ile znaków zajmie N bajtów?” oraz „ile bajtów kryje się za ciągiem o długości M?” (drugi tryb to dolna granica bez znajomości paddingu).
Dlaczego Base64 powiększa dane
- Każde 3 bajty (24 bity) mapują się na 4 znaki po 6 bitów → stały stosunek 4:3.
- Gdy długość nie dzieli się przez 3, dokładane są
=(padding), żeby długość ciągu była wielokrotnością 4. - W API string Base64 siedzi w JSON jako tekst — najpierw płacisz narzut encodingu, dopiero potem ewentualny gzip całego body.
Typowy wzrost dla większych bloków to ok. +33%. Przy bardzo małych payloadach procent wygląda gorzej przez padding (np. 1 B → 4 znaki).
Szybka tabela: bajty → Base64
Kanoniczny wzorzec 4:3 — wpisz lewą kolumnę w trybie „rozmiar binarny”.
| Bajty (raw) | Znaki Base64 | Narzut | Uwaga |
|---|---|---|---|
| 3 | 4 | +33% | dokładnie 1 triplet |
| 1 | 4 | +300% | padding dominuje |
| 1024 (1 KiB) | 1368 | +33,6% | typowy plik/blob |
| 204800 (200 KB) | 273068 | +33,3% | obraz w JSON |
Wynik w kalkulatorze liczy ceil(n/3)×4 — bez łamania linii MIME.
Padding i jak czytać tryby kalkulatora
- Bajty → Base64 — dokładny rozmiar ciągu (z liczbą
=w notatce). - Długość Base64 → bajty —
floor(len×3/4); bez paddingu to dolna granica. - Base64URL (JWT) ma inny alfabet, ale ten sam stosunek 4:3 — do tokenów użyj też kalkulatora JWT.
Kiedy narzut Base64 naprawdę ma znaczenie
- Pola
content/filew JSON z binariami inline. - Załączniki MIME, webhooki z dużymi blobami, limity body na API gateway.
- Data-URI w CSS/HTML (plus prefiks
data:…;base64,) — duże assety lepiej jako URL pliku. - Logi i kolejki, które indeksują tekst: puchnięcie o ⅓ szybko zjada retention.
Przykłady liczbowe
- 3 B → 4 znaki — klasyczny minimalny blok.
- 1024 B → 1368 znaków (+33,6%).
- Obraz 200 KB w JSON → ok. 267 KB tekstu Base64 — odpowiedź API puchnie zanim włączysz gzip.
- Mały token 16 B → 24 znaki: procentowo „dużo”, absolutnie nadal mało — oceń w kontekście limitu body.
FAQ — narzut Base64
Pytania o encoding overhead, padding i limity payloadów.
- Ile wynosi typowy wzrost Base64?
- Dla większych bloków zwykle ok. +33% (4 znaki na 3 bajty). Małe dane mogą mieć wyższy procent przez padding.
- Czy Base64 kompresuje dane?
- Nie. To encoding do tekstu. Gzip/Brotli to osobny krok na HTTP body — nie myl z Base64.
- Po co są znaki „=”?
- Padding do wielokrotności 4 znaków, gdy liczba bajtów nie dzieli się przez 3. Tryb bajty→Base64 pokazuje ich liczbę.
- Dlaczego tryb „długość → bajty” to szacunek?
- Bez paddingu dolna granica to floor(len×3/4). Dokładniej liczysz ze znanego rozmiaru binarnego.
- Czy data-URI też rośnie o ~33%?
- Tak względem bajtów pliku, plus prefiks
data:…;base64,. Duże assety serwuj jako pliki. - Base64 vs Base64URL w JWT?
- Ten sam stosunek 4:3; inny alfabet/padding. Do planowania tokena użyj kalkulatora rozmiaru JWT.
- Czy gzip „cofa” narzut Base64?
- Częściowo zmniejsza transfer całego body, ale limity gateway często liczą nieskompresowane bajty — i tak płacisz za dłuższy tekst w JSON.
- 1 B → 4 znaki — czy to zawsze +300%?
- Tak procentowo przy 1 bajcie. Przy 1 KiB narzut wraca do ~33%. Patrz na absolutne bajty, nie tylko procent.