快速开始
-
粘贴 URL 或参数
支持完整链接或单独查询值。
-
选择编码模式
参数值用「组件编码」；整段 URL 用「完整 URI」。
-
复制结果
编码后可直接用于 fetch 或浏览器地址栏测试。
URL 编码/解码
URL 编码（percent-encoding）将非 ASCII 与保留字符转为 %XX 形式，确保查询参数与路径在 HTTP 传输中不被误解析。本工具支持 encodeURIComponent 与 decodeURIComponent 双向转换，帮助排查双重编码、加号与空格差异等问题。解析完整 URL 结构请用 url-parser，JWT 或 Basic Auth 中的 Base64 请用 base64-encoder-decoder。
阅读完整指南: Base64 与 URL 编码：区别、场景与常见错误 →
隐私提示：本地解析，不上传服务器。
↓ 在下方输入区粘贴内容，结果会立即显示
编码范围
在此输入 URL 或编码字符串
支持中文与特殊字符，选择编码或解码模式。
输出结果
编码结果
https%3A%2F%2Ftowalles.com%2Fsearch%3Fq%3D%E4%BD%A0%E5%A5%BD%26lang%3Dzh-CN
注释说明
编码结果
使用 encodeURIComponent，适合查询参数值（会编码 ?、&、= 等）。 完整 URI: https://towalles.com/search?q=%E4%BD%A0%E5%A5%BD&lang=zh-CN
URL 编码（percent-encoding）将非 ASCII 与保留字符转为 %XX 形式，确保查询参数与路径在 HTTP 传输中不被误解析。本工具支持 encodeURIComponent 与 decodeURIComponent 双向转换，帮助排查双重编码、加号与空格差异等问题。解析完整 URL 结构请用 url-parser，JWT 或 Basic Auth 中的 Base64 请用 base64-encoder-decoder。
为什么需要 URL 编码
URL 只能安全携带 ASCII 子集。中文和空格等字符必须转成 %XX 形式。
两种编码的区别
encodeURIComponent 会编码 ?、&、=; 适合单个参数值。
encodeURI 保留 URL 结构; 只编码非法字符。
典型工作流
当你在开发需要传递参数的 Web 应用时，URL 编码是必经步骤。比如，用户搜索「咖啡店」时，浏览器会自动将其编码为 %E5%92%96%E5%95%A1%E5%BA%97 再发送。使用本工具可快速验证编码结果是否符合预期，或在调试 API 时手动生成测试用例。
解码场景同样常见。收到类似 %7B%22error%22%3A%20404%7D 的响应时，直接粘贴到工具中即可还原为可读的 JSON 结构。我们还建议收藏此页面，在排查前端路由异常或后端参数解析错误时能快速定位问题。
encodeURIComponent 边界
encodeURIComponent 编码除 A-Z a-z 0-9 - _ . ! ~ * ' ( ) 外的字符，适合 query 参数值。整段 URL 勿直接 encode——会误编码 :// 与 ?。完整 URL 拆解请用 url-parser。
加号 + 在 application/x-www-form-urlencoded 中表示空格，但 JSON 或 RFC 3986 场景应使用 %20。双重编码（%252F）导致服务端解析为字面 %2F 而非 /——解码一次后检查是否仍含 %。
OAuth 与 redirect 调试
OAuth redirect_uri 必须精确匹配注册值，包括 trailing slash 与编码。本工具验证 client_id、state 等参数 encode 后是否仍可读。JWT 在 query 中传递时，Base64 的 + 常被误转为空格——配合 base64-encoder-decoder 与 jwt-decoder。
中文搜索词、emoji 参数需 UTF-8 percent-encoding。某些旧系统用 GBK，跨系统联调时 charset 不一致会乱码。
与 HTML 实体区别
URL 编码 (%XX) 用于 HTTP 地址；HTML 实体 (&) 用于 markup。json-formatter 格式化含 URL 的 JSON 后，再对本工具 encode 单个字段值，避免整段 JSON 被误编码。
分享含 token 的 URL 前，用 pii-scanner 扫描 query 是否含 key= 模式；生产 URL 脱敏 state 与 code 参数。
Path 段与 query 分段编码
path 段中的斜杠有语义，不可整体 encode；应对每一段单独 encode（中文目录名、空格文件名）。query 则对每个 value 使用 encodeURIComponent 风格编码，再以 & 连接。混用两种规则是「本地预览正常、服务端 404」的常见原因。
调试完成后用 url-parser 反查：确认 decode 后的 path/query 是否与网关路由表一致。含 state/code 的 OAuth URL 分享前脱敏，并用 pii-scanner 扫一遍。
国际化与旧系统 charset
现代栈应坚持 UTF-8 percent-encoding。若对端声明 GBK/GB2312，浏览器默认 UTF-8 编码会导致乱码——需在服务端转码，而不是反复 encode。emoji 与合字在部分旧网关会被截断，先用短 ASCII 对照验证通道。
把失败用例写成单测：输入原文、期望编码串、服务端解码结果。本工具用于人工对照；回归靠 CI。
表单、重定向与双重编码陷阱
浏览器提交 application/x-www-form-urlencoded 时会编码一次；若你的后端再 encode 一次，下游会看到 %253A 这类「双重编码」。联调时在本工具先 encode 得到期望串，再与抓包对比。OAuth redirect_uri 必须与控制台登记值字节级一致，多一个尾斜杠都会失败。
重定向链上每一跳都可能再次编码。用 url-parser 拆解最终落地 URL，确认 query 中的 token 未被截断。分享前脱敏 code/state。
与 API 网关、CDN 规则对齐
部分网关默认拒绝含 %2F 的 path，或对 query 大小写敏感。先在本工具生成候选 URL，再在预发网关用同一字符串探测。日志里看到的已是解码或再编码后的形态，不要拿日志原文直接当「客户端发送值」。
把成功与失败的 URL 样本收进契约测试。配合 json-formatter 检查错误响应里返回的「规范 URL」字段是否与请求一致。
回调 URL 与 OAuth redirect 排错
OAuth redirect_uri 必须与控制台登记值字节级一致，包括是否编码、是否带尾斜杠。用本工具分别编码 path 段与 query 值，再用 url-parser 还原对照。常见失败：把整段 URL 二次 encode，或把已编码的 redirect 再塞进另一层 query。
排查时在笔记中保留：登记值、实际发出值、中间代理改写后的值。涉及 state/code 的链接分享前脱敏，并用 pii-scanner 扫描剪贴板导出。
表单 application/x-www-form-urlencoded 对照
许多网关把 body 按 form-urlencoded 解析。空格可能是 + 或 %20，取决于库。用本工具生成期望编码，与抓包结果逐字段对比；不要只看「肉眼可读」。嵌套 JSON 字段应先确认是否应作为整体 encode，还是应改为 multipart。
把通过的用例固化为集成测试。本工具负责人工对齐；回归靠自动化。
示例
编码
Input
你好
Output
%E4%BD%A0%E5%A5%BD
解码
Input
%E4%BD%A0%E5%A5%BD
Output
你好
FAQ
解码报错怎么办？
通常是 % 后面不是合法十六进制; 或字符串被截断。
和 Base64 一样吗？
不一样。URL 编码用于地址栏与查询参数; Base64 用于二进制文本化。
为什么编码后的 URL 有时不一致？
不同编程语言或库的默认编码规则可能不同。比如空格在 JavaScript 中被编码为 %20，而 Python 的 urllib 可能生成 + 号。本工具遵循现代浏览器标准，默认采用 %20 方案。调试时请确认前后端使用相同的编码标准。
空格编码为 + 还是 %20？
表单提交常用 +；RFC 3986 推荐 %20。与对接方保持一致。
为何 decode 后仍乱码？
可能双重编码、charset 错误或 Base64 层未剥离。逐层 decode 并确认 UTF-8。
要编码整个 URL 吗？
一般只编码 query 值或 path 段；整 URL encode 会破坏结构。
本地处理吗？
是，encode/decode 均在浏览器完成。
path 里的中文要编码吗？
要。对每个 path 段编码；保留结构斜杠。用 url-parser 验证往返。
和 html 实体编码有何不同？
URL 编码用于地址传输；HTML 实体用于页面 markup。勿把 JSON 整段当成 URL 编码。
空格该变成 + 还是 %20？
query 的 form 编码常用 +；path 与现代 encodeURIComponent 风格用 %20。按对端规范选择并保持一致。
整段 JSON 放进 query 可以吗？
可以但难看且易超长。优先 POST body；若必须放 query，先压缩再严格 encode，并设长度上限。
为什么 encode 两次？
常见于「先拼完整 URL 再整体 encode」或代理层重复处理。用 url-parser 看 decode 一层后是否仍含 %XX。
保留字符要不要编码？
取决于位置：query 值中的 & = # 必须编码；作为分隔符的结构字符不要编码。