图片转 Base64

最常见原因是格式前缀不匹配。CSS 的 background-image 属性需要完整的 data URL 格式，例如 `background-image: url("data:image/png;base64,iVBOR...")`。本工具默认输出纯 Base64 字符串，需要手动在「输出格式」下拉选「CSS 格式」，工具会自动补全 `data:image/...;base64,` 前缀和 url() 包裹。如果已经选了 CSS 格式还不行，检查 CSS 文件是否保存为 UTF-8 无 BOM 编码，以及引号是否被编辑器转义。

可以，但需要正确的格式。在 HTML 中，img 标签的 src 属性接受完整的 data URL：`<img src="data:image/png;base64,iVBOR...">`。本工具在「HTML 格式」输出模式下，会直接生成带 data URL 前缀的完整字符串，复制后粘贴到 src 属性值位置即可。注意：Base64 字符串通常很长，如果图片超过几百 KB，生成的字符串会让 HTML 文件体积剧增，影响页面加载速度，建议只对几十 KB 以内的小图标或小图使用。

这是 Base64 编码的原理决定的，不是工具的问题。Base64 用 64 个可打印字符表示二进制数据，每 3 个字节的原始数据会被编码成 4 个 Base64 字符，再加上换行符（可选）和 data URL 前缀，最终体积大约比原图大 33%–37%。例如一个 100 KB 的 PNG 图片，转成纯 Base64 字符串大约 136 KB，如果带上 data:image/png;base64, 前缀则更大。这个膨胀是固定的，与图片格式或本工具无关。

不会。本工具是纯前端实现（FE），所有图片处理都在浏览器本地完成。当你选择图片后，工具通过 FileReader API 读取图片文件的二进制内容，直接在内存中进行 Base64 编码，整个过程不经过任何后端服务器，也没有网络请求上传图片数据。关掉页面或清除浏览器缓存后，图片数据即被释放。如果需要绝对离线使用，可以访问一次页面后断网，工具仍然能正常工作（因为所有逻辑代码已加载到本地）。

本工具没有硬性限制，但受浏览器和可用内存的制约。理论上，只要浏览器能读取的文件都可以转，但实际中：图片文件超过 50 MB 时，浏览器读取和编码过程可能会卡顿甚至崩溃，因为 Base64 编码需要将整个文件读入内存并分配约 1.37 倍于原文件大小的字符串内存。建议日常使用控制在 10 MB 以内，超过 50 MB 的图片建议先压缩再转换，或改用后端工具处理。另外，某些移动端浏览器对超大 Base64 字符串的显示和复制支持较差。

本工具默认输出的 Base64 字符串每 76 个字符插入一个换行符（\n），这是遵循 RFC 2045（MIME）规范的做法，便于在邮件或某些旧协议中传输。如果需要在 CSS、HTML 或 JavaScript 代码中使用，换行符通常可以保留，因为大多数解析器会忽略空白。但如果需要严格的单行字符串（例如放在 URL 参数或 JSON 字段中），本工具在「输出格式」选择「纯字符串」模式时，会输出无换行的紧凑格式。如果当前输出有换行，请确认输出格式设置为「纯字符串」或「dataURL」而非「CSS」或「HTML」。

这是因为手机照片通常包含 EXIF 方向信息（例如旋转 90°），而 Base64 编码只处理像素数据，不处理 EXIF 元数据。本工具编码时读取的是图片的原始二进制内容，保留了 EXIF 信息，但大多数浏览器在显示 Base64 图片时不自动应用 EXIF 方向。解决方法：在转换前，先用图片编辑软件（或本工具所在网站的图片压缩/裁剪工具）将图片按正确方向重新保存，消除 EXIF 旋转标记，再进行 Base64 转换。或者，在 HTML 中引用图片时，通过 CSS 的 image-orientation: from-image 属性让浏览器读取 EXIF 方向。

区别主要在体积和用途。JPG 有损压缩，原图较小，转 Base64 后体积膨胀相对不明显，适合照片类大图。PNG 无损压缩，原图可能较大，转 Base64 后膨胀明显，适合需要透明背景的图标。GIF 支持动图，转 Base64 后动图特性保留，但文件通常较大，不推荐用于长动画。SVG 本身就是文本格式，转 Base64 后体积膨胀较少，但通常没必要——直接内联 SVG 代码更小且可维护。从划算角度：体积小（<10KB）且使用次数少的图片适合转 Base64 嵌入，减少 HTTP 请求；大图转 Base64 反而让页面变慢。