URL Кодувальник / Декодувальник

Закодуйте будь-який текст у безпечний для URL рядок з percent-encoding або декодуйте закодований URL назад у звичайний текст. Живий попередній перегляд, підтримка UTF-8, повністю у вашому браузері.

Режим

Сприймати + як пробіл під час декодування

Звичайний текст

0 симв.

Закодований результат

0 симв.

Чому iKit URL Encoder

Швидкий, точний, працює лише в браузері — створений для розробників, копірайтерів і всіх, хто налагоджує URL.

Три режими кодування

Оберіть режим Component, Full URI або Form залежно від того, що ви кодуєте — значення query-string, цілий URL чи payload HTML-форми.

Конфіденційність за замовчуванням

Кожне кодування й декодування виконується у вашому браузері за допомогою нативного JavaScript. Ваш текст і URL ніколи не залишають пристрій.

Живий попередній перегляд

Результат оновлюється з кожним натисканням клавіші — без кнопки «Кодувати», без звернень до сервера.

Підтримка UTF-8

Емодзі, ієрогліфи CJK, латиниця з діакритикою та кирилиця коректно проходять через encodeURIComponent і назад.

Обробка + у стилі форм

Під час декодування за бажанням сприймайте «+» як пробіл — конвенція, яку HTML-форми використовують у application/x-www-form-urlencoded.

Пакетна обробка файлів

Перетягніть файл.txt,.csv або.json, щоб закодувати чи декодувати його за один крок. Результат завантажується як чистий.txt.

Як насправді працює URL-кодування

Три нативні API браузера, три режими — і все це виконується на сторінці, яку ви читаєте.

1

Ви вводите текст у редакторі

На кожне натискання клавіші вхідний рядок передається у невелику JavaScript-функцію. Жодного debounce, жодних API-викликів, жодного fetch — функція виконується синхронно у вкладці вашого браузера.
2

Оберіть режим

Component викликає encodeURIComponent — екранує все, що не є A-Z a-z 0-9 - _. ~. URI викликає encodeURI — зберігає :/?#=&, щоб цілий URL лишався чинним. Form використовує encodeURIComponent і замінює пробіл на + згідно application/x-www-form-urlencoded.
3

UTF-8 працює автоматично

Як encodeURIComponent, так і encodeURI внутрішньо конвертують рядок у байти UTF-8 перед percent-encoding кожного небезпечного байта. Тож ви отримуєте %E4%B8%AD для китайського 中 — саме те, що вимагає RFC 3986.
4

Результат з'являється наживо

Результат записується як значення поля виводу лише для читання. Натисніть Copy, щоб помістити його в буфер обміну через navigator.clipboard.writeText, або Download, щоб зберегти як .txt через Blob URL — обидві операції лишаються у вашому браузері.

Поширені сценарії використання

Реальні ситуації, коли правильний режим кодування рятує від багів.

Формування значень query-string

Будь-який користувацький ввід, який ви додаєте у ?q=..., треба кодувати в режимі Component. Режим URI лишив би = та & сирими, що ламає URL, коли значення містить ці символи.

Поширення довгого URL у чаті

Деякі чати та PDF псують посилання, що містять сирі пробіли або не-ASCII символи. Прожене URL через режим URI, щоб він безпечно копіювався скрізь.

Налагодження бекенду, що повертає 400

Коли ваше API відхиляє запит, вставте URL у режим Decode, щоб побачити, що насправді отримав сервер. Подвійно закодовані значення (де сам % закодовано як %25) одразу впадають в око.

Round-trip даних форми

Коли ви налагоджуєте POST-тіла у application/x-www-form-urlencoded, декодуйте з увімкненою опцією «+ як пробіл». Це конвенція, яку використовують браузери, і забути про неї — причина багу №1 «чому моє ім'я користувача показується з плюсами».

Чому локальне кодування має значення

URL, які ви кодуєте, часто містять реальні email клієнтів, ідентифікатори або токени сесій — саме ті дані, які не варто вставляти в чужий серверний інструмент. iKit URL Encoder працює як JavaScript, уже завантажений у ваш браузер, тож ввід ніколи не залишає вкладку.

Жодного fetch, XHR чи beacon під час кодування або декодування.
Працює офлайн після того, як сторінку завантажено.
Без логів, без обмежень швидкості, без реєстрації, без щоденних квот.

Пов'язані посібники

Детальні посібники та порівняння інструментів з блогу iKit.

Часті запитання

У чому різниця між режимами Component, URI та Form?

Component (encodeURIComponent) екранує все, що не є unreserved-символом, — найбезпечніший варіант для значень query-string, сегментів шляху чи окремого поля. URI (encodeURI) зберігає структурні символи URL (:/?#=&) — застосовуйте його до цілого URL. Form (application/x-www-form-urlencoded) — це Component плюс пробіли стають «+» — саме так роблять HTML-форми.

Чому деякі символи не кодуються?

RFC 3986 визначає набір «unreserved»-символів, які не потребують кодування: A-Z a-z 0-9 - _. ~. Усе інше отримує percent-encoding. encodeURIComponent додатково кодує :/?#&=, які encodeURI лишає як є. Ця різниця важлива, коли ви кодуєте значення параметра проти цілого URL.

Чому декодований текст виглядає неправильно?

Три типові причини: (1) оригінал був Form-кодований, тож «+» слід трактувати як пробіл — увімкніть відповідну опцію. (2) Подвійне кодування — ввід було закодовано двічі; декодуйте ще раз. (3) Некоректна percent-послідовність — самотній % без двох hex-цифр після нього. Перевірте повідомлення про помилку для точної позиції байта.

Чи закодований URL точно такий самий, як у JavaScript-функції encodeURIComponent?

Так для режиму Component — ми викликаємо encodeURIComponent безпосередньо. Режим Form додає стандартні правки form-encoding (! ' * стають %21 %27 %28 %29 %2A) згідно RFC 3986 та WHATWG. Режим URI викликає encodeURI — те, що більшість мов мають на увазі під «percent-encode для URL».

Чи завантажуються мої URL кудись?

Ні. Увесь інструмент — це JavaScript усередині цієї сторінки: кодування й декодування відбуваються у вашому браузері. Можете перевірити: відкрийте DevTools → Network і подивіться — жодних запитів під час операцій кодування чи декодування не надсилається.