Skip to content

Koder i dekoder URL z wbudowanym parserem URL

Dekoduj i koduj adresy URL z wbudowanym parserem URL. Tryb podwójny: encodeURI i encodeURIComponent. 100% prywatnie, bez wysyłki na serwer.

Bez śledzenia Działa w przeglądarce Bezpłatne
Zdekodowane
Zakodowane
Zweryfikowano pod kątem zgodności z RFC 3986, poprawności encodeURI/encodeURIComponent oraz dokładności kodowania UTF-8 — Zespół inżynierski Go Tools · Apr 7, 2026

Czym jest kodowanie URL (kodowanie procentowe)?

Kodowanie URL, formalnie znane jako kodowanie procentowe, to mechanizm zdefiniowany w RFC 3986, służący do reprezentowania w Uniform Resource Identifier (URI) znaków niedozwolonych lub mających specjalne znaczenie. Zamienia każdy niebezpieczny bajt na znak procentu (%), po którym następują dwie cyfry szesnastkowe — na przykład spacja staje się %20, ampersand staje się %26, a chiński znak 中 staje się %E4%B8%AD (jego trzy bajty UTF-8, każdy zakodowany procentowo).

URL-e mogą zawierać tylko ograniczony zestaw znaków z ASCII. Litery, cyfry i garść symboli (- _ . ~) są uznawane za „niezarezerwowane” i mogą pojawić się bez zmian. Wszystkie inne znaki — w tym spacje, interpunkcja i cały zakres Unicode — muszą być kodowane procentowo, aby bezpiecznie podróżować w URL. Znaki zarezerwowane, takie jak ?, &, = i #, pełnią rolę separatorów strukturalnych w składni URL, więc muszą być kodowane również wtedy, gdy używane są jako dosłowne dane, a nie separatory.

Kodowanie procentowe jest niezbędne w całym webie: przeglądarki kodują wysyłane formularze, API wymagają zakodowanych parametrów zapytania, przepływy OAuth zależą od poprawnie zakodowanych redirect URI, a zinternacjonalizowane nazwy domen opierają się na kodowaniu znaków spoza ASCII. Nieprawidłowe kodowanie prowadzi do zepsutych linków, luk bezpieczeństwa (jak ataki open redirect) oraz uszkodzenia danych.

To narzędzie udostępnia oba tryby — encodeURI i encodeURIComponent — wbudowany parser struktury URL, konwersję w czasie rzeczywistym oraz wykrywanie podwójnego kodowania — wszystko działa prywatnie w przeglądarce.

Kodowanie URL często stosuje się obok innych narzędzi deweloperskich. Można potrzebować zakodować URL w Base64 w celu osadzenia w tokenie JWT lub payloadzie API, albo sformatować dane JSON zawierające ciągi URL, aby zbadać ich strukturę. Aby dokładniej przyjrzeć się kodowaniu procentowemu na poziomie bajtów, warto przeczytać nasz kompletny przewodnik po kodowaniu URL dla programistów.

// Encode a query parameter value
const param = encodeURIComponent('hello world & goodbye');
console.log(param); // → 'hello%20world%20%26%20goodbye'

// Encode a full URL (preserves structure)
const url = encodeURI('https://example.com/path name?q=hello world');
console.log(url); // → 'https://example.com/path%20name?q=hello%20world'

// Decode a percent-encoded string
const decoded = decodeURIComponent('hello%20world%20%26%20goodbye');
console.log(decoded); // → 'hello world & goodbye'

// Build a URL with encoded parameters
const base = 'https://api.example.com/search';
const query = `?q=${encodeURIComponent('你好')}&lang=zh`;
console.log(base + query); // → 'https://api.example.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh'

Najważniejsze funkcje

Dwa tryby kodowania

Przełączaj między encodeURI (zachowuje strukturę URL) a encodeURIComponent (koduje wszystko dla wartości parametrów), aby dopasować tryb do konkretnego zastosowania.

Wbudowany parser URL

Automatycznie rozkłada każdy URL na protokół, host, port, ścieżkę, parametry zapytania i fragment — każde pole jest edytowalne i można z nich odbudować nowy URL.

Konwersja w czasie rzeczywistym

Kodowanie i dekodowanie odbywa się natychmiast podczas pisania — bez przycisków, wyniki pojawiają się w drugim polu z każdym naciśnięciem klawisza.

100% po stronie przeglądarki

Całe przetwarzanie odbywa się lokalnie w przeglądarce, z wykorzystaniem natywnych API JavaScript. Dane nigdy nie opuszczają urządzenia — brak przesyłania na serwer, brak śledzenia.

Pełna obsługa UTF-8

Poprawnie obsługuje znaki chińskie, japońskie, koreańskie, arabskie, emoji oraz dowolny tekst Unicode dzięki prawidłowemu kodowaniu i dekodowaniu bajtów UTF-8.

Wykrywanie podwójnego kodowania

Automatycznie wykrywa i ostrzega o problemach z podwójnym kodowaniem, takich jak %2520 (zakodowany procentowo %20), pomagając uniknąć jednego z najczęstszych błędów kodowania URL.

Przykłady

Dekodowanie zniekształconego URL

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dhello%20world%26lang%3Den
https://example.com/search?q=hello world&lang=en

W pełni zakodowany procentowo URL jest dekodowany z powrotem do czytelnej formy, ujawniając oryginalne parametry zapytania i strukturę

Znaki chińskie

https://example.com/search?q=你好世界
https://example.com/search?q=%E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C

Znaki chińskie są konwertowane na sekwencje bajtów UTF-8 i kodowane procentowo

Parametry zapytania

https://example.com/api?name=John Doe&role=admin&lang=en&sort=date desc
https://example.com/api?name=John%20Doe&role=admin&lang=en&sort=date%20desc

Spacje i znaki specjalne w wartościach parametrów zapytania są kodowane procentowo z zachowaniem struktury URL

Pełny URL

https://user:pass@example.com:8080/path/to/page?key=value&arr[]=1#section-2
https://user:pass@example.com:8080/path/to/page?key=value&arr%5B%5D=1#section-2

Kompletny URL z danymi uwierzytelniającymi, portem, ścieżką, parametrami zapytania z nawiasami oraz identyfikatorem fragmentu

OAuth redirect URI

https://auth.example.com/authorize?redirect_uri=https://myapp.com/callback?code=abc&state=xyz
https://auth.example.com/authorize?redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz

Wartość redirect_uri sama w sobie zawiera pełny URL, który musi zostać zakodowany, aby jego znaki specjalne nie były interpretowane jako część zewnętrznego URL

Jak używać

  1. 1

    Wprowadź URL lub zakodowany ciąg

    Wklej URL w polu zdekodowanym, aby go zakodować, lub wklej ciąg zakodowany procentowo w polu zakodowanym, aby go zdekodować. Wybierz tryb encodeURI lub encodeURIComponent w zależności od zastosowania.

  2. 2

    Sprawdź wyniki i sparsowaną strukturę

    Drugie pole aktualizuje się natychmiast podczas pisania. Parser URL rozkłada adres na protokół, host, port, ścieżkę, parametry zapytania i fragment — wszystkie edytowalne.

  3. 3

    Skopiuj lub odbuduj

    Kliknij Kopiuj, aby skopiować zakodowany lub zdekodowany wynik. Edytuj poszczególne komponenty URL i kliknij Odbuduj, aby z modyfikowanych części zbudować nowy URL.

Częste błędy

Podwójne kodowanie (%2520 zamiast %20)

Podwójne kodowanie występuje wtedy, gdy już zakodowany URL jest kodowany ponownie. Znak % w %20 zostaje zakodowany jako %25, zmieniając %20 w %2520. Łamie to URL, ponieważ serwer widzi dosłowny ciąg %20 zamiast spacji.

✗ Niepoprawne 
https://example.com/path%2520with%2520spaces
✓ Poprawne 
https://example.com/path%20with%20spaces

Spacja kodowana jako + w segmentach ścieżki

Znak + reprezentuje spację tylko w formacie application/x-www-form-urlencoded (ciągi zapytań z formularzy HTML). W segmentach ścieżki URL + jest interpretowany jako dosłowny plus, a nie spacja. W segmentach ścieżki dla spacji należy zawsze używać %20.

✗ Niepoprawne 
https://example.com/my+file+name.pdf
✓ Poprawne 
https://example.com/my%20file%20name.pdf

Użycie encodeURI na wartościach parametrów zapytania

encodeURI() nie koduje znaków &, = ani innych znaków zarezerwowanych, więc użycie go na wartości parametru zawierającej takie znaki psuje strukturę ciągu zapytania.

✗ Niepoprawne 
encodeURI('key=value&more')  → 'key=value&more' (& not encoded!)
✓ Poprawne 
encodeURIComponent('key=value&more')  → 'key%3Dvalue%26more'

Zakładanie kodowania innego niż UTF-8

Niektóre starsze systemy używają kodowań takich jak Latin-1 czy Shift-JIS dla parametrów URL. Nowoczesne standardy wymagają UTF-8. Dekodowanie parametru zakodowanego w Shift-JIS za pomocą dekodera UTF-8 daje uszkodzony tekst.

✗ Niepoprawne 
Decoding %82%B1%82%F1 as UTF-8 (this is Shift-JIS for こん)
✓ Poprawne 
Using UTF-8: %E3%81%93%E3%82%93 correctly decodes to こん

Kodowanie ścieżek względnych bez kontekstu

Zakodowanie ścieżki względnej typu ../images/photo.jpg za pomocą encodeURIComponent zamienia ukośniki i kropki w sekwencje zakodowane procentowo, łamiąc strukturę ścieżki. Należy używać encodeURI() lub kodować jedynie poszczególne segmenty ścieżki.

✗ Niepoprawne 
encodeURIComponent('../images/photo.jpg')  → '..%2Fimages%2Fphoto.jpg'
✓ Poprawne 
Encode each segment: '../images/' + encodeURIComponent('my photo.jpg')

Typowe zastosowania

Debugowanie zniekształconych URL-i
Dekoduj URL-e zakodowane procentowo z logów serwera, komunikatów błędów lub narzędzi deweloperskich przeglądarki, aby odczytać oryginalny, czytelny tekst.
Rozwój API
Koduj wartości parametrów zapytania dla wywołań REST API, aby znaki specjalne takie jak &, = czy spacje nie psuły URL żądania.
Konfiguracja przepływu OAuth
Prawidłowo koduj redirect_uri oraz inne parametry URL w adresach autoryzacji OAuth, aby uniknąć błędów uwierzytelniania.
Zinternacjonalizowane URL-e
Koduj i dekoduj adresy URL zawierające znaki chińskie, japońskie, koreańskie, arabskie lub inne spoza ASCII w międzynarodowych aplikacjach webowych.
Analiza linków marketingowych
Dekoduj URL-e śledzące z kampanii e-mailowych i platform reklamowych, aby zrozumieć osadzone parametry UTM oraz łańcuchy przekierowań.
Inspekcja struktury URL
Parsuj złożone adresy URL na części składowe — protokół, host, port, ścieżkę, parametry zapytania i fragment — w celu analizy i modyfikacji.

Szczegóły techniczne

Znaki zarezerwowane i niezarezerwowane w RFC 3986
RFC 3986 definiuje znaki niezarezerwowane (A-Z, a-z, 0-9, -, ., _, ~), które nigdy nie wymagają kodowania, oraz znaki zarezerwowane (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =), które pełnią rolę separatorów URI i muszą być kodowane procentowo, gdy występują jako dane.
Przepływ kodowania bajtów UTF-8
Znaki spoza ASCII są najpierw konwertowane na punkt kodowy Unicode, następnie kodowane jako bajty UTF-8 (1-4 bajty w zależności od zakresu punktu kodowego), a na końcu każdy bajt jest kodowany procentowo jako %XX. Na przykład: é (U+00E9) → bajty UTF-8 C3 A9 → %C3%A9. Emoji 🎉 (U+1F389) → bajty UTF-8 F0 9F 8E 89 → %F0%9F%8E%89.
Terminologia URL vs URI
URI (Uniform Resource Identifier) to ogólne określenie dowolnego ciągu identyfikującego. URL (Uniform Resource Locator) to URI, który dodatkowo wskazuje sposób dostępu (np. https://). Reguły kodowania z RFC 3986 dotyczą wszystkich URI. API JavaScriptu używa terminologii URI (encodeURI, decodeURI), podczas gdy w codziennym użyciu dominuje URL.

Dobre praktyki

Używaj właściwego trybu do zadania
Do pojedynczych kluczy i wartości parametrów zapytania używaj encodeURIComponent(). encodeURI() stosuj tylko wtedy, gdy masz pełny URL i chcesz zakodować znaki niebezpieczne bez łamania jego struktury. Nigdy nie używaj encodeURI() na wartościach parametrów, które mogą zawierać &, = lub inne znaki zarezerwowane.
Unikaj podwójnego kodowania
Przed zakodowaniem ciągu należy sprawdzić, czy nie jest już zakodowany. Warto szukać istniejących sekwencji %. Zakodowanie już zakodowanego ciągu zamienia %20 w %2520, %3D w %253D i tak dalej. W razie wątpliwości należy najpierw zdekodować, a potem zakodować raz.
Dekoduj po stronie serwera
Większość frameworków webowych automatycznie dekoduje parametry URL, zanim dotrą do kodu aplikacji. Warto unikać ręcznego dekodowania parametrów, które framework już zdekodował — może to powodować problemy, jeśli oryginalna wartość zawierała dosłowne sekwencje procentowe.
Koduj wartości dla OAuth i podpisywania API
Ciągi bazowe podpisów OAuth 1.0 oraz wiele algorytmów podpisywania API wymaga ścisłego kodowania procentowego zgodnego z RFC 3986. Należy używać encodeURIComponent(), a następnie zastąpić pozostałe znaki, których funkcja nie koduje (jak !, ', (, ), *), ich odpowiednikami zakodowanymi procentowo, jeśli wymaga tego specyfikacja.

Najczęściej zadawane pytania

Czym jest kodowanie URL i dlaczego jest niezbędne?
Kodowanie URL (kodowanie procentowe) zamienia niebezpieczne znaki na sekwencje szesnastkowe %XX, dzięki czemu mogą być bezpiecznie umieszczane w adresach URL. Znaki takie jak spacje, ampersandy i tekst spoza ASCII muszą być kodowane, ponieważ w przeciwnym razie psułyby strukturę URL lub byłyby błędnie interpretowane przez przeglądarki i serwery. Mechanizm ten, zdefiniowany w RFC 3986, działa dlatego, że URL może zawierać jedynie ograniczony zestaw znaków US-ASCII — litery (A-Z, a-z), cyfry (0-9) oraz kilka symboli, takich jak myślniki, podkreślenia, kropki i tyldy. Każdy znak spoza tego bezpiecznego zestawu jest kodowany jako znak procentu (%), po którym następują dwie cyfry szesnastkowe reprezentujące wartość bajtu. Na przykład spacja staje się %20, ukośnik staje się %2F, a ampersand staje się %26. Znaki takie jak &, =, ? i # mają w URL specjalne znaczenie strukturalne — oddzielają parametry zapytania, fragmenty i inne komponenty. Bez kodowania dosłowny & w wartości parametru zostałby błędnie zinterpretowany jako separator parametrów, całkowicie łamiąc strukturę URL.
Jaka jest różnica między encodeURI a encodeURIComponent?
encodeURI() koduje pełny URL, zachowując znaki strukturalne takie jak :, /, ? i #. encodeURIComponent() koduje wszystko z wyjątkiem liter, cyfr oraz - _ . ~, co czyni je właściwym wyborem do kodowania pojedynczych wartości parametrów zapytania. Należy używać encodeURIComponent() dla kluczy i wartości parametrów, a encodeURI() tylko dla kompletnych adresów URL. Na przykład encodeURI('https://example.com/path name') daje 'https://example.com/path%20name', zachowując :// oraz /. encodeURIComponent() jest znacznie bardziej agresywny — koduje :, /, ?, #, & i =. Użycie encodeURI() na wartości parametru zawierającej ampersand spowoduje, że & przejdzie bez zakodowania i zostanie błędnie zinterpretowany jako separator parametrów. encodeURIComponent() poprawnie zakoduje go jako %26. Pomylenie tych dwóch funkcji jest jedną z najczęstszych przyczyn błędów związanych z URL w aplikacjach webowych.
Czy kodowanie URL to to samo co kodowanie HTML?
Nie. Kodowanie URL zamienia znaki na sekwencje szesnastkowe %XX dla adresów URL (RFC 3986), natomiast kodowanie HTML zamienia znaki na encje takie jak & i < dla dokumentów HTML. Służą całkowicie różnym celom i nigdy nie powinny być stosowane zamiennie. Kodowanie URL służy do transportu danych wewnątrz adresów URL — spacja staje się %20. Kodowanie HTML służy do bezpiecznego wyświetlania treści w HTML — ampersand staje się &. Częstym błędem jest stosowanie kodowania HTML do parametrów URL lub odwrotnie. Na przykład zakodowanie spacji jako   w URL nie zadziała — musi to być %20 lub +. Podobnie użycie %3C w tekście HTML zamiast < nie zapewni pożądanego escape'owania.
Dlaczego mój URL łamie się, gdy używam go w poleceniu curl?
Powłoka interpretuje specjalne znaki URL, zanim zobaczy je curl: & uruchamia polecenia w tle, ? wywołuje globbing, a # rozpoczyna komentarz. Można to naprawić, otaczając URL pojedynczymi cudzysłowami: curl 'https://example.com/api?key=value&page=2#section'. Pojedyncze cudzysłowy zapobiegają interpretowaniu przez powłokę jakichkolwiek znaków specjalnych. Ampersand (&) jest najczęstszym winowajcą — każe powłoce uruchomić poprzedzające polecenie w tle, dzieląc URL w miejscu pierwszego & i odrzucając wszystko, co znajduje się po nim. Alternatywnie można escape'ować poszczególne znaki ukośnikami wstecznymi, ale otoczenie całego URL cudzysłowami jest prostsze i mniej podatne na błędy. Jeśli URL zawiera również pojedyncze cudzysłowy, warto użyć cudzysłowów podwójnych i escape'ować znaki dolara lub grawisy.
Dlaczego znaki chińskie stają się ciągami typu %E4%B8%AD w adresach URL?
Znaki chińskie są najpierw konwertowane na bajty UTF-8, a następnie każdy bajt jest kodowany procentowo jako %XX. Znak 中 (U+4E2D) staje się trzema bajtami UTF-8 (E4, B8, AD), co daje %E4%B8%AD — dlatego jeden znak chiński rozszerza się do 9 znaków w URL. Ten trzystopniowy proces — znak do punktu kodowego Unicode, punkt kodowy do bajtów UTF-8, bajty do szesnastkowego kodowania procentowego — dotyczy wszystkich znaków spoza ASCII. Emoji często wymagają 4 bajtów UTF-8, przez co rozszerzają się do 12 znaków po zakodowaniu procentowym. Podczas dekodowania URL proces przebiega odwrotnie: wartości szesnastkowe są konwertowane z powrotem na bajty, bajty są interpretowane jako UTF-8 i oryginalne znaki zostają odtworzone.
Czy powinienem kodować parametr OAuth redirect_uri?
Tak, zawsze należy kodować go za pomocą encodeURIComponent(). redirect_uri to pełny URL osadzony jako wartość parametru zapytania, więc jego znaki specjalne (?, &, =) muszą zostać zakodowane, aby nie były błędnie interpretowane jako część struktury zewnętrznego URL. Na przykład redirect_uri=https://myapp.com/callback?code=abc&state=xyz bez kodowania sprawi, że serwer autoryzacji zobaczy redirect_uri tylko jako https://myapp.com/callback?code=abc, podczas gdy state=xyz zostanie sparsowany jako osobny parametr zewnętrznego URL. Prawidłowo zakodowana wersja to redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback%3Fcode%3Dabc%26state%3Dxyz.
Jaka jest różnica między querystring z Node.js a URLSearchParams?
W nowych projektach należy używać URLSearchParams — to standard WHATWG, odpowiada zachowaniu przeglądarki i działa identycznie w Node.js oraz w przeglądarkach. Moduł querystring jest przestarzały i nie jest już aktywnie rozwijany. Kluczowe różnice: URLSearchParams koduje spacje jako + (standard kodowania formularzy), obsługuje powtarzające się klucze przez getAll() i udostępnia iterowalny interfejs z metodami entries(), keys() i values(). Moduł querystring koduje spacje jako %20 i ma dziwactwa przy obsłudze tablic (key=1&key=2 staje się { key: ['1', '2'] }). URLSearchParams jest zgodny ze standardami i rekomendowany przez samą dokumentację Node.js.
Jak zakodować URL w Pythonie, JavaScripcie i Javie?
JavaScript: encodeURIComponent('hello world') daje 'hello%20world'. Python: urllib.parse.quote('hello world') daje 'hello%20world'. Java: URLEncoder.encode('hello world', StandardCharsets.UTF_8) daje 'hello+world' (zamień + na %20 dla zgodności z RFC 3986). W JavaScripcie używaj encodeURIComponent() do wartości parametrów oraz encodeURI() do pełnych adresów URL. W Pythonie 3 używaj urllib.parse.quote() do segmentów ścieżki oraz urllib.parse.urlencode() do parametrów zapytania — urlencode({'q': 'hello world'}) daje 'q=hello+world'. W Javie warto pamiętać, że URLEncoder używa kodowania formularzy (spacje jako +). Do budowania kompletnych URI służy java.net.URI lub klasa URIBuilder z Apache HttpClient.
Które znaki nie są kodowane w kodowaniu URL?
RFC 3986 definiuje 66 znaków niezarezerwowanych, które nigdy nie wymagają kodowania: A-Z, a-z, 0-9, myślnik (-), kropka (.), podkreślenie (_) oraz tylda (~). Mogą one pojawić się dosłownie w dowolnej części URL. Znaki zarezerwowane — :, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ;, i = — są dozwolone w swoich rolach strukturalnych (jak ? dla ciągów zapytań), ale muszą być kodowane procentowo, gdy są używane jako dosłowne dane. W JavaScripcie encodeURIComponent() koduje wszystko z wyjątkiem A-Z a-z 0-9 - _ . ~ oraz ! ' ( ) *, natomiast encodeURI() dodatkowo zachowuje znaki zarezerwowane pełniące rolę separatorów URL.
Jaka jest różnica między + a %20 przy kodowaniu spacji?
Oba znaki reprezentują spację, ale %20 jest uniwersalnie bezpiecznym wyborem. Konwencja + pochodzi z kodowania formularzy HTML (application/x-www-form-urlencoded) i działa tylko w ciągach zapytań. W segmentach ścieżki URL + jest dosłownym znakiem plus, a nie spacją. W razie wątpliwości należy używać %20. Kodowanie + pochodzi ze specyfikacji HTML — gdy przeglądarki wysyłają formularze, spacje stają się +, a sam znak + staje się %2B. Kodowanie %20 pochodzi z RFC 3986 (składnia URI), gdzie każdy znak nienależący do niezarezerwowanych jest kodowany jako znak procentu, po którym następują dwie cyfry szesnastkowe. %20 działa we wszystkich częściach URL: ścieżce, zapytaniu i fragmencie.
Jak kodowanie URL obsługuje emoji?
Pojedyncze emoji zazwyczaj rozszerza się do 12 znaków w URL. Emoji są konwertowane na bajty UTF-8 (zwykle 4 bajty), a następnie każdy bajt jest kodowany procentowo jako %XX. Na przykład 🚀 (U+1F680) staje się %F0%9F%9A%80. Większość emoji używa punktów kodowych w zakresie od U+1F000 do U+1FFFF lub wyższych, które wymagają 4 bajtów w UTF-8. Niektóre emoji z modyfikatorami odcienia skóry lub sekwencjami ZWJ składają się z wielu punktów kodowych i mogą rozszerzać się do ponad 30 znaków po zakodowaniu. Mimo tego rozszerzenia kodowanie jest w pełni odwracalne — dekodowanie %F0%9F%9A%80 poprawnie odtwarza 🚀.
Czy kodowanie URL może być używane do szyfrowania lub zabezpieczeń?
Nie. Kodowanie URL nie jest szyfrowaniem i nie zapewnia żadnego bezpieczeństwa. Jest w pełni odwracalną, deterministyczną transformacją — każdy może natychmiast zdekodować ciąg zakodowany procentowo bez żadnego klucza ani sekretu. Istnieje wyłącznie po to, by escape'ować znaki specjalne dla bezpiecznego transportu w URL. Traktowanie kodowania URL jako obfuskacji lub zabezpieczenia to niebezpieczne nieporozumienie. Wrażliwe dane, takie jak hasła, tokeny czy informacje osobowe, powinny być chronione przez HTTPS (szyfrowanie TLS całego żądania), a nie przez kodowanie URL. Ponadto URL-e często pojawiają się w logach serwera, historii przeglądarki i nagłówkach Referer, więc dane wrażliwe powinno się co do zasady przesyłać w treści żądania, a nie w adresie URL.
Jaka jest maksymalna długość adresu URL?
Nie istnieje oficjalne maksimum, ale warto utrzymywać URL-e poniżej 2000 znaków dla maksymalnej kompatybilności. Większość przeglądarek obsługuje około 2048 znaków, Apache domyślnie 8190 bajtów, a Nginx 8192 bajty. W przypadku dużych danych warto używać żądań POST zamiast GET. Specyfikacje HTTP (RFC 7230) nie definiują maksymalnej długości URL, ale praktyczne limity istnieją na każdej warstwie. Chrome i Firefox potrafią obsłużyć URL-e przekraczające 100 000 znaków, podczas gdy IIS ogranicza ciągi zapytań do 16 384 bajtów. CDN-y i proxy mogą mieć jeszcze bardziej restrykcyjne limity. Gdy kodowanie URL rozszerza znaki — zwłaszcza tekst spoza ASCII — pozornie krótki URL może szybko zbliżyć się do tych limitów.
Jaka jest różnica między URL a URI?
URI (Uniform Resource Identifier) to dowolny ciąg identyfikujący zasób. URL (Uniform Resource Locator) to URI, który dodatkowo wskazuje, jak uzyskać dostęp do zasobu za pomocą protokołu takiego jak https://. Wszystkie URL-e są URI, ale nie wszystkie URI są URL-ami — na przykład URN typu urn:isbn:0451450523 identyfikuje książkę po numerze ISBN, ale nie mówi, gdzie ją znaleźć. W codziennej pracy nad webem terminy URL i URI są często używane zamiennie. Reguły kodowania zdefiniowane w RFC 3986 dotyczą obu. Funkcje w JavaScripcie noszą nazwy encodeURI/decodeURI, odzwierciedlając szerszą terminologię URI, mimo że większość programistów pracuje wyłącznie z URL-ami.

Powiązane narzędzia

Zobacz wszystkie narzędzia →

Koder i dekoder Base64

Kodowanie i formatowanie

Zakoduj i zdekoduj Base64 online za darmo. Konwersja w czasie rzeczywistym z pełną obsługą UTF-8 i emoji. 100% w przeglądarce, bez rejestracji.

Formatowanie i walidacja JSON

Kodowanie i formatowanie

Formatuj, waliduj i upiększaj JSON w przeglądarce. Bezpłatne narzędzie z kontrolą składni, wykrywaniem błędów i minifikacją. 100% prywatnie.

Konwerter systemów liczbowych — binary, hex, decimal i octal

Narzędzia konwersji

Konwertuj między systemami binarnym, szesnastkowym, dziesiętnym i ósemkowym (2–36) w czasie rzeczywistym. Bezpłatnie i prywatnie — w przeglądarce.

Kompresor obrazów online — JPEG, PNG i WebP

Narzędzia konwersji

Kompresja JPEG, PNG i WebP nawet o 80% — w przeglądarce, bez przesyłania na serwer. Wsadowo do 20 obrazów, porównanie przed i po. Prywatnie.

Dekoder JWT

Narzędzia bezpieczeństwa

Dekoduj JWT online darmowym dekoderem JWT. Sprawdź header, payload, signature, claims i wygaśnięcie. W 100% w przeglądarce — token nie opuszcza urządzenia.

Przelicznik długości — metryczne, imperialne i więcej

Narzędzia konwersji

Przelicz 16 jednostek długości natychmiast — metryczne, imperialne, morskie i astronomiczne. 1 cal = 2,54 cm. Za darmo, prywatnie, w przeglądarce.