工具用的顺手吗？
你的反馈能帮助我们做得更好
将文本与Base64字符串相互转换，支持标准与URL安全编码，适配UTF-8等多种字符集。
概览
了解工具能解决的问题、计算或处理逻辑，以及数据边界。
输入“你好”，标准模式会得到5L2g5aW9；输入“Hello World”，结果是SGVsbG8gV29ybGQ=。这里发生的是编码而不是加密：文本先按UTF-8转换为字节，再把每3个字节组成的24位数据拆成4组、每组6位，并用64个可打印字符表示。解码则按相反方向还原字节，再把字节解释为UTF-8文本。
若原始字节数为n，带填充的标准Base64长度为4 × ceil(n / 3)。因此短文本常会变长；末尾不足3个字节时用一个或两个=补齐输出分组。页面只接收和输出文本，不是任意文件上传器，也没有Latin-1等字符集选择项。
字母表末两位使用+和/，并按需要保留=填充。它适合明确要求标准Base64文本的接口、配置或测试数据。
编码时把+替换为-、把/替换为_，并移除末尾填充。解码时会做反向替换并自动补足填充。以“😃”为例，标准结果是8J+Ygw==，URL安全结果是8J-Ygw。
两种模式不能只凭“看起来像一串Base64”自动判定。若输入包含-或_且省略填充，应先开启URL安全模式；标准模式不会替你转换这些字符。
指南
按步骤完成操作，并通过示例核对输入与结果。
“编码”接收普通文本，“解码”接收Base64字符串。切换模式后，示例按钮也会改用与当前方向匹配的样例。
普通Base64保持关闭；需要base64url字母表并去掉填充时开启。解码已有字符串时，开关必须与来源格式一致。
输入变化后结果自动计算。输出区显示字符数，可直接复制；若字符串含非法字符、填充不正确，或解码后的字节不是有效UTF-8，输出会清空并显示解码错误。
| 模式 | 输入 | 预期输出 | 核对点 |
|---|---|---|---|
| 标准编码 | Hello World | SGVsbG8gV29ybGQ= | 末尾保留一个填充符 |
| 标准编码 | 你好 | 5L2g5aW9 | 中文按UTF-8字节编码 |
| URL安全编码 | 😃 | 8J-Ygw | +变为-且去掉== |
排查自己的数据时，先用表中样例确认模式正常，再替换为目标字符串。这样可把“工具模式选错”和“上游数据本身有问题”分开判断。
场景
查看这项工具在不同工作与生活流程中的用法。
配置文件或消息体只能安全容纳文本时，可先把一段UTF-8文字编码，再复制结果。接收方必须约定同一种Base64变体和字符编码。
JWT片段或其他URL上下文常见base64url形式。这里可用于观察字符替换与填充差异，但不会校验令牌签名、权限或业务含义。
先解码一个已知样例，再检查目标内容。若标准与URL安全模式都失败，问题可能是字符串被截断、混入空白以外的字符，或原始数据并非UTF-8文本。
问答
集中解答高频疑问与容易混淆的问题。
不是。它只改变数据的表示方式，不提供密钥、机密性或身份验证；任何拿到字符串的人都可以尝试解码。密码、访问令牌和私密正文不能靠Base64本身保护。
先确认标准模式与URL安全模式是否匹配。该页面把还原出的字节按UTF-8解释；若原数据使用其他字符集、内容被截断，或它本来是图片等二进制数据，就不能得到可读文本。
URL安全模式会按长度自动补齐填充后再解码；标准模式则按输入原样解析。省略填充是否被允许取决于具体协议，不能把所有无等号字符串都视为同一种格式。
4比3描述的是完整字节分组。短输入还受填充影响，中文和表情又会占多个UTF-8字节；URL安全模式还会移除末尾等号，所以字符数需要按实际UTF-8字节计算。
须知
使用前了解适用范围、结果限制与必要提醒。
推荐
查找相关工具、专题与可用的 API 能力。
