Screenshot to text: select it off the image and copy
Text inside a screenshot that you cannot select, search or copy is the most common small annoyance in this category of tool. kuaika lays the recognised lines back over the positions they came from, so you drag-select and copy exactly as you would on a web page. And when you want the text rather than the picture, there is a shorter route. The model runs on your own computer — this step makes no network request at all.
Last updated 2026-09-09
Two routes, because there are two different needs
The first route is capture first, extract second. Once the selection is set, press Ctrl+T and the recognised lines are laid back over their original coordinates — every line sits exactly where it appeared on screen, so you drag-select it like a web page and press Ctrl+C. Press Ctrl+T again to put the text layer away and go back to normal annotation. This fits "I still want to annotate and save this image, and while I am here I want to copy one paragraph out of it".
The second route skips the image entirely. Ctrl+Shift+T enters text mode: finish the selection and recognition starts automatically, with the result going straight to the clipboard. No image is produced and nothing is written to disk. This fits the one-off cases — an uncopyable paragraph on a web page, a file path inside an error dialog, an address in a picture somebody sent you.
Both routes run the same recognition; the only difference is where the result goes. Most people settle on the second one, because it is two steps shorter.
Recognition runs on your machine, and not one byte is uploaded
The model is a local PP-OCRv5 mobile pair: 4.5MB for detection, 15.8MB for recognition, plus a dictionary. All three ship inside the installer, so there is nothing to download. Inference runs on onnxruntime-web through WebAssembly, which means the whole path contains no native module and makes no outbound request.
That is not a promise you have to take on trust. The client, the native addon and even this website live in a single repository, so you can read exactly what gets captured, where it is written and whether anything leaves the machine. If you would rather not trust a build somebody else produced, clone it and compile your own. A screenshot tool can see your entire screen; putting the source in front of you is the only honest response to that.
One design trade-off is worth stating plainly: the model files are not optional. If they are missing, the "extract text" button does not appear at all rather than appearing and then failing. A missing button is better than a button that does nothing.
Why not the OCR built into Windows
It was tried and then ruled out on measurements, not on impressions. Three options were benchmarked:
- Windows.Media.Ocr: 27 milliseconds, wonderfully fast, but unusable for Chinese — it split short Chinese phrases into isolated characters and mangled "ChatGPT" into fragments. Ruled out immediately.
- Large models in the OvisOCR2-0.9B class: accurate, and capable of tables and formulas, but they need an extra 0.8 to 1.9GB of runtime and weights. More decisively, they are page-level document parsers that do not return per-line coordinates — which makes the "lay it back over the original and select it" interaction impossible.
- PP-OCRv5 mobile: 1.6 seconds cold (including model load), about 470 milliseconds warm, and 5 out of 5 exact line matches on synthetic images. Balancing accuracy, size and coordinate support, it was the only one of the three that satisfied all of them.
The recognition layer keeps a provider seam. If page-level document parsing is added later (tables to HTML, formulas to LaTeX — things PP-OCR cannot give), it forks at the recognition entry point; the toolbar, the text layer and the shortcuts do not change.
Paste keeps the layout, because the breaks are computed
Recognition returns lines with quadrilateral boxes, not paragraphs, and joining them naively is exactly how extracted text ends up as one long smear. The line breaks are computed from geometry: skew is estimated from the median angle of wide, clearly horizontal boxes; boxes that overlap vertically by more than half the reference height are clustered into a visual line; within a line, horizontal gaps and CJK-to-Latin boundaries decide whether a space belongs there; and between lines there is always a newline.
A blank line is inserted only when the gap exceeds both a typographic minimum and 1.55 times the median line spacing. The median matters: one large heading or an embedded image produces a couple of outlier gaps five to ten times the normal spacing, and an average would be dragged high enough that no real paragraph break ever qualifies.
The same structure drives drag-selection. The main process attaches the separator that belongs in front of each line and ships it down with the result, so the renderer reassembles any subset from that — which means "copy everything" and "copy what I selected" cannot disagree.
When recognition disappoints, check these first
- Text too small: the input is literally the pixels on your screen. At low system scaling with a small font, enlarging the target before capturing helps far more than retrying.
- A sleeping display, a lock screen or a UAC secure desktop returns an all-black frame, so recognition finds zero lines. In that case the problem is capture, not OCR.
- Decorative type, vertical text and heavily skewed text are outside the comfort zone of a mobile-class model. That is the trade you get in exchange for the startup time and the package size.
- Recognition is transient: the text layer is not baked into the PNG and does not follow a pinned image. If you want to keep the text, copy it.
Keys for extracting text
| Key / entry point | What it does |
|---|---|
| Ctrl+Shift+A | Region capture; decide afterwards whether you want the text |
| Ctrl+T | Extract text: lines are laid back over the original and can be drag-selected; press again to hide |
| Ctrl+C | Copy the selected text (or everything, if nothing is selected) |
| Ctrl+Shift+T | Capture to text: finish the selection, recognition runs, text goes to the clipboard, no image |
| Esc | Leave the current mode |
Frequently asked
- Does screenshot-to-text need internet? Is anything sent to a server?
- No, and no. The model ships with the installer and runs locally. The whole application makes network requests in exactly three places, and we list all of them: a version check five seconds after launch (carrying nothing about you); when you press "download model" in Settings (those are two optional models for gallery search and to-do extraction, unrelated to text extraction); and, only if you enable "include page content in search", fetching the public page behind a URL found in a screenshot. The last two are optional. There is no account, no cloud and no telemetry.
- How long does one recognition take?
- About 1.6 seconds the first time, because the model has to load, then roughly 470 milliseconds while warm. The inference window is destroyed after five idle minutes, so the next use pays the cold start again.
- Does the extracted text keep the original layout?
- It keeps the line structure. Lines are positioned at their original coordinates, so selection order matches what you see, and paragraph breaks are computed from the spacing. It does not reconstruct table structure or convert formulas.
- Does it handle English and numbers?
- Yes. PP-OCRv5 is a mixed Chinese-English model, so Latin text and digits come back in the same pass.