这个工具适合做什么
URL 编码用于把中文、空格、加号、斜杠、问号等特殊字符转换为浏览器和服务器更容易安全传递的形式；URL 解码则把这些转义结果还原为可读文本。本页适合处理查询参数、回调地址、跳转链接和接口调试时遇到的编码问题。
常见使用场景
- 把中文参数、搜索词或过滤条件安全地拼接进 URL。
- 排查接口请求里被编码后的回调地址、重定向地址和搜索参数。
- 确认某段日志、网关配置或浏览器地址栏中的字符串原文。
- 和 Base64 编码、Unicode 编码 配合分析复杂字符串。
使用步骤
- 左侧粘贴原始文本，工具会实时输出 URL 编码结果。
- 右侧输入待解码的字符串，工具会尝试还原原文。
- 若右侧报错，先检查是否存在不完整的
%转义片段。
示例
原始文本: a+b c/中文
编码结果: a%2Bb%20c%2F%E4%B8%AD%E6%96%87这类编码结果常见于查询参数和跳转地址中，再次解码即可还原为原始文本。
容易出错的地方
- 很多场景应该编码“参数值”而不是整个 URL。
- 重复编码会让原本正确的参数再次被转义，导致服务器无法按预期解析。
- 含有中文或特殊符号的字符串如果直接拼接进地址栏，最容易在代理、网关或日志里出问题。
常见问题
什么时候应该做 URL 编码？
当参数值中包含空格、中文、加号、斜杠、问号、井号等特殊字符时，通常都应先做 URL 编码，避免参数边界被误判或内容被截断。
应该编码整个 URL，还是只编码参数值？
大多数情况下应只编码参数值，而不是把完整 URL 整体编码。否则协议头、路径分隔符和问号等结构字符也会被转义，反而不利于后续拼接和解析。
为什么有些系统把空格显示成加号而不是 %20？
这通常来自表单编码规则。当前工具按通用 URL 组件编码逻辑处理，空格会编码为 %20。如果你面对的是特定表单协议，需要结合目标系统规则判断。
为什么解码时报“不是有效的 URL 编码字符串”？
这说明输入里存在不完整的百分号转义片段，或混入了非法字符。先确认来源是否经过完整编码，再重新复制粘贴更稳妥。
相关工具
如果你还在排查更底层的字符串问题，可以继续使用 Base64 编码/解码、Unicode 编码/解码 和 字符编码转换。