Przykład 1
- 200 znaków
- chars-to-bytes
≈ 150 B
Ile B z 200 znaków? ≈ 150 B. Szacunek Base64, nie dekoder JWT.
Rozmiar tokena JWT
Wpisz znaki albo bajty. 200 znaków dają ≈ 150 B. 300 B w trybie bajtów zostaje ≈ 300 B. 1024 znaki dają ≈ 768 B. Szacunek Base64, nie dekoder JWT.
To floor(n×3/4) ze znaków albo ceil(n/3)×4 w drugą stronę. Wynik jest linią bajtów. Nie dekoder. Narzut 4 na 3 jest na rozmiarze Base64.
Wynik
Wprowadź dane i kliknij Oblicz.
Jak to działa?
Rozmiar tokena JWT na tej karcie szacuje bajty z długości. 200 znaków dają ≈ 150 B. 300 w trybie bytes-to-chars zostaje ≈ 300 B, bo primary jest linią bajtów. 1024 znaki dają ≈ 768 B. To szacunek Base64, nie dekoder JWT.
Pole jwt-chars jest liczbą. Select jwt-base w przykładach to chars-to-bytes, bytes-to-chars i znowu chars-to-bytes. floor(200×3/4) = 150. 300 B zostaje 300 po stronie bajtów. floor(1024×3/4) = 768.
150 B nie jest zdekodowanym payloadem. 300 B nie jest weryfikacją podpisu. 768 B nie zna nagłówka Authorization. Wpisujesz długość sam. Karta nie parsuje JWT.
Rozmiar Base64 obok liczy ceil(n/3)×4. Szacunek JSON mnoży znaki. Tu 200 zostaje ≈ 150 B, sam narzut 3 na 4.
Wpisz 200 i chars-to-bytes, potem Oblicz. Wynik to ≈ 150 B. Zero zostawia 0 B. To nie dekoder tokena.
200 dają ≈ 150 B. 300 B zostaje ≈ 300 B. 1024 dają ≈ 768 B. Inny tryb przy 200 zmienia kartę, wynik trzyma bajty.
Wzór
znaki do bajtów: floor(n×3/4). Bajty do znaków: ceil(n/3)×4. Wynik jest linią B. Nie dekoder JWT.
Jak korzystać
- Wpisz 200 i tryb chars-to-bytes.
- Kliknij Oblicz. Wynik to ≈ 150 B.
- 300 w bytes-to-chars zostaje ≈ 300 B. 1024 dają ≈ 768 B.
- To szacunek Base64, nie dekoder JWT.
- Narzut 4 na 3 licz na rozmiarze Base64.
200 znaków = ≈ 150 B
Szacunek Base64, nie dekoder JWT. 200 dają ≈ 150 B. 1024 dają ≈ 768 B.
- Rozmiar
- Linia B. 200 znaków zostawia ≈ 150 B. Nie payload.
- tokena
- Długość z pola. 300 B zostaje ≈ 300 B. Nie weryfikacja.
- JWT
- Szacunek 3 na 4. 1024 dają ≈ 768 B. Nie dekoder.
Przykłady
Przykład 2
- 300 B
- bytes-to-chars
≈ 300 B
Ile przy 300 B w bytes-to-chars? ≈ 300 B. Wynik zostaje linia bajtów.
Przykład 3
- 1024 znaki
- chars-to-bytes
≈ 768 B
Ile z 1024 znaków? ≈ 768 B.
Powiązane kalkulatory
Najczęstsze pytania
Ile B z 200 znaków?
≈ 150 B. floor(200×3/4). Szacunek Base64, nie dekoder JWT.
Ile przy 300 B w bytes-to-chars?
≈ 300 B. Wynik jest linią bajtów.
Ile z 1024 znaków?
≈ 768 B. floor(1024×3/4).
Czy karta dekoduje JWT?
Nie. Sama długość. Nie ma podpisu i nie ma payloadu.
Po co jwt-base?
chars-to-bytes idzie do B. bytes-to-chars idzie do znaków. Wynik zostaje B.
Czy 150 B to cookie po zapisie?
Nie. Szacunek 3 na 4. Nie plik i nie header dump.
Czy zero liczy?
Tak jako 0 B. Pusty wpis to błąd liczby.
Gdzie liczysz narzut Base64 z bajtów?
Na rozmiarze Base64. Tu zostaje ≈ 150 B z 200.
Czy to walidator tokena?
Nie. Brak iss, exp i podpisu. Sama długość.
Dlaczego rozmiar JWT ma znaczenie
JWT wraca w Authorization, cookie lub body przy każdym (lub prawie każdym) requestcie. Większy token = więcej bajtów × RPS, ryzyko limitu cookie (~4 KB) i odrzucenia przez proxy.
Ten kalkulator liczy orientacyjny rozmiar ze znaków Base64URL lub z bajtów przed kodowaniem. Nie dekoduje claims i nie ocenia bezpieczeństwa.
Co składa się na długość tokena
- Header — zwykle krótki (
alg,typ). - Payload — claims; tu najczęściej rośnie token.
- Signature — stały narzut zależny od algorytmu (HMAC vs RSA/ECDSA).
Trzy segmenty Base64URL oddzielone kropkami — token.length w DevTools to liczba znaków na przewodzie.
Claims: kiedy token staje się mini-bazą
- Listy ról/uprawnień jako długie stringi w payloadzie.
- Cały profil użytkownika zamiast
sub+ lookup po stronie API. - Zagnieżdżone obiekty i powtórzone dane „na wszelki wypadek”.
„Dokładaj claims” ma koszt: każdy request wozi tę samą bagażnicę. Często lepszy jest krótki access token + dane w sesji/cache.
Cookie, headery i limity infrastruktury
- Cookie przeglądarki: praktycznie ~4 KB na cookie — 3000+ znaków JWT to czerwona flaga.
- Łączny rozmiar nagłówków bywa limitowany przez CDN/proxy/load balancer.
- Mobile i słabe łącza: powtarzalny narzut na każde API call.
Rozmiar ≠ bezpieczeństwo
Krótki token nie jest „bezpieczniejszy”, a długi nie jest „bezpieczniejszy” — to osobna oś (podpis, TTL, rotacja, audience). Ten kalkulator pomaga tylko nie przekroczyć limitów transportowych i nie wozić zbędnych bajtów.
Przykłady rozmiaru (orientacyjnie)
Tryb znaki → bajty używa floor(n×3/4).
| Znaki tokena | ≈ bajty | Intuicja |
|---|---|---|
| ~200 | ~150 B | zwięzły access token |
| ~800 | ~600 B | kilka claims + role |
| ~3000 | ~2250 B | blisko limitu cookie |
| ~5000+ | — | rozważ opaque session / referencję |
Policz dokładniej: skopiuj cały token i użyj token.length.
FAQ — rozmiar JWT
Rozmiar i transport — bez mylenia z dekodowaniem.
- Czy ten kalkulator dekoduje JWT?
- Nie. Szacuje rozmiar z długości znaków lub bajtów. Nie weryfikuje podpisu ani claims.
- Znaki czy bajty — co wpisać?
- Token z DevTools → tryb znaki→bajty. Jeśli znasz bajty JSON claims przed Base64URL → bajty→znaki.
- Dlaczego duży JWT w cookie boli?
- Limit ~4 KB, każde żądanie dociąga cookie, proxy może odrzucić zbyt duże headery.
- Czy mniej claims zawsze lepsze?
- Dla rozmiaru — tak. Model autoryzacji (ID + lookup vs fat token) to osobna decyzja.
- Base64 vs Base64URL?
- JWT używa Base64URL; stosunek 3→4 jest ten sam do planowania rozmiaru.
- Jak zmierzyć dokładnie?
- Skopiuj trzy segmenty z kropkami i policz
token.lengthw JS. - Czy RS256 zawsze robi większy token niż HS256?
- Podpis RSA/ECDSA bywa dłuższy; dokładny rozmiar zależy od klucza. Payload claims często i tak dominuje.
- Co zamiast tłustego JWT?
- Krótki access token + session/store po stronie serwera, albo referencyjne ID sesji w cookie HttpOnly.