图片转文字：把字取出来，接着干正事
构建挂了。报错是四十行堆栈信息，出现在一台你没法复制的机器的终端上——远程控制台、被锁死的虚拟机、 同事贴进群里的截图。字你看得清清楚楚，就是选不中，而手动重新敲一遍 Java 包路径，正是拼写错误诞生 的地方。
这个页面就是为此而生的。上传截图，图里的文字会被识别出来，以纯文本返回，可以直接贴进搜索框、AI 助手 或工单。是对像素跑真正的 OCR，不是对文件做描述。支持 JPG、JPEG、PNG、GIF、BMP、TIFF、TIF 和 WebP。 免费、免注册、单文件 50 MB，用完不留任何东西。这就是免费在线图片转文字最字面的形态： 丢一张图进去，把字拿出来。
从截图到搜索框的闭环
大家需要从截图提取文字的最常见原因，是想把这些字放进一个只收文字的地方。搜索引擎 不收图片，工单系统的搜索、日志聚合平台，以及你想贴一段异常去问模型"这是啥"的那个输入框，也都不收。
于是闭环就是：截图、转换、粘贴。十秒钟，差别是实打实的——拿到精确异常类名和行号的助手会给出具体的 答案，拿到一句模糊转述的只会给一份通用检查清单。错误弹窗、CI 输出、数据库报错、崩溃报告，全都同理。 只要它以字符的形式出现在屏幕上而你选不中，这就是绕过去的办法。
纯文本还是 Markdown？说句实话
大多数网站会在这里编出一个戏剧性的区别。实情没那么戏剧化：对于简单的图片——一段文字的截图、一个 终端窗口、一张便签——纯文本和 Markdown 的结果基本一模一样。识别出的文字按行返回，一段散文里没有 任何隐藏结构可供 Markdown 补充。随便选哪个都不吃亏。
真正开始有差别的，是画面里有"形状"的时候：表格、表单、带标题的文档页。Markdown 能承载这种排布， 纯文本只能用空格勉强示意。那种情况去 图片转 Markdown 更合适。 其余的一切——"其余"覆盖了绝大多数截图——纯文本是更干净的产物：进脚本、进索引、进 diff 之前，没有 任何语法字符需要剥。
顶部的格式切换按钮能在两种格式间来回切，并保留你已经选好的文件，两种都试只花一次上传。
它悄悄解决的日常琐事
- 终端和日志输出。回滚不回去的会话里的命令输出，或者轮转之前抢拍下来的日志窗口。 变成文本之后就能 grep、能 diff、能拿去提问。
- 聊天和邮件截图。以图片而非文字转发的对话——也就是绝大多数对话。转一次，就有了 能引用、能检索的东西。
- 招牌、标签和包装。序列号铭牌、接线标签、产品规格面板的照片。重新打字很烦， 转换很轻松。
- 手写笔记。值得一试，但预期要现实——工整的手写体识别得比连笔潦草字好得多， 结果一定要对照原件核一遍。
- 只能看、不能复制的代码。视频画面里、幻灯片上、锁定文档中的代码片段。提出来变成 文本，再配上你的GitHub 仓库文本或 GitLab 项目，助手就能同时看到 片段和你的代码库。
- 从网站上截下来的一切。这个习惯值得改掉—— Web2Txt 直接抓取页面并保留链接， HTML 转 Markdown 则能处理另存的网页。回到源头永远胜过读像素。
识别在哪里生效，在哪里失效
有一条规则能解释所有值得了解的失败情形：OCR 只作用于你上传的那个图片文件，不作用于埋在其他文件里 的图片。图片藏在更大的容器里时会被跳过，因为转换器读的是容器。
- 扫描版 PDF 什么都转不出来。纯图像 PDF 里没有文字，OCR 也不会穿过 PDF 外壳去够 里面的像素。从源头解决：用 Acrobat、macOS 的"预览"或几乎任何现代 PDF 阅读器执行"识别文本"， 把它变成可检索的 PDF，再走 PDF 转文本或 PDF 转 Markdown。 扫描文档的正确归宿在那边。
- ZIP 里的图片只会被列出，不会被读取。压缩包转换给你的只有文件名。 ZIP 转文本适合一文件夹的 文档；图片请解压出来，一张一张单独上传。
- 嵌在 Word、PowerPoint、RTF、EPUB 或邮件里的图片不会被读取。它们在输出里只是一个 图片占位符。一份用截图拼起来的 DOCX 走 Word 转 Markdown， 得到的是周围的文字加上图片位置上的窟窿。把图片另存出来，到这里转。
把这个模型记在脑子里，你就永远不会浪费一次上传：想读图，就把图本身交出来。
批量处理，以及喂给机器
当输出的去处不是人时，纯文本正是你要的格式。一摞图片识别出的文字可以干净地拼接、可预测地切块、 不带任何格式噪音地生成 embedding——给一堆截图建搜索索引，或者把拍照存档的资料变成可检索的东西时， 要的正是这个。
实际操作是一次上传一张图——压缩包会跳过图片——所以按循环来规划，别指望一次批量。输出下方的 token 计数器在这里很有用：在你把多页叠进一个提示词或者规划切块策略之前，它先告诉你每次转换实际花多少。 文档和图片混在一起的语料， File2Txt 在一个地方处理所有 支持的格式，本地目录转换则能一趟把 项目里基于文本的那部分全部压平。
让识别器过得轻松点
准确率跟图片质量的关系紧密到这样的程度：几个习惯对结果的改变比任何设置都大：
- 能截图就别拍屏幕。没有反光、没有角度、没有虚焦、没有屏幕摩尔纹。
- 紧贴目标文字裁剪。每个字符占的像素越多越好，还能防止输出被你不想要的界面元素塞满。
- 图片摆正、尽量正对。歪斜的文字行比端正的难读。
- 能避开的困难场景尽量避开：低分辨率截图、叠在照片上的文字、手写体和花体字，以及半截在阴影里的 东西。这些不是不能转，只是错误就爱扎堆在这里。
- 要紧的内容一定校对。编号里认错一个数字既无声又昂贵，扫五秒钟输出就能抓出来。
常见问题
怎么把 JPG 图片转成文字？
把图片拖进上方的转换器。OCR 直接跑在像素上，识别出的文字以纯文本返回，可选中、可搜索、可粘贴。免费、免注册、单图 50 MB。这就是最字面意义上的 jpeg 转文字——图进、字出，什么都不用装。
PNG 和其他图片格式也支持吗？
支持：JPG、JPEG、PNG、GIF、BMP、TIFF、TIF 和 WebP 都行。PNG 是绝大多数截图的格式，也是 OCR 的最理想输入——截图是渲染出来的文字，不是纸的照片，没有相机虚焦、没有页面弯曲、没有光照不均要对付。
手写笔记能识别吗？
识别得很差，你应当按"不能"来预期。OCR 模型压倒性地在印刷体上训练；连笔字和匆忙的大写体产出的结果看着像模像样，错的恰恰是你想不到要去核对的地方。横格纸上工整的印刷体大写偶尔能过。除此之外都需要对照原件校对，而校对的成本通常比重新打字还高。
为什么我的图片识别出来的字符是错的？
几乎总是分辨率的问题。OCR 需要约 300 DPI 等效的清晰度才能分开相似的形状，低于这个水平，rn 会粘成 m，1 和 l 互换，0 变成 O。手机凑近一点再拍，或者按完整窗口尺寸截屏、不要缩小，大部分问题就没了。
拍下来的文档页照片能提取文字吗？
能，而且效果比一般人预想的好——但先把页面"摆平"。相机与纸面平行而不是斜着拍，光线均匀、文字上没有阴影，页面填满取景框。梯形畸变或有阴影的照片会整行整行地丢字，而且 OCR 丢的时候不报任何错。
转换之后图片会被保存在哪里吗？
不会。图片发送过去识别，处理完、文字返回后即被丢弃——不存档、不用于训练、不建索引。没有账号与之关联，我们这边也不保留副本。
这里的其他一切
图片旁边还有十二种支持的格式，都能从 File2Txt 进入。想看通用版而不是 图片专属版的论证，还有一篇更长的 为 LLM 准备文件的指南。
Repo2Txt 由 v12hero 开发和维护，那是一位独立开发者，专做隐私优先的原生应用和 Web 应用。