Use this for handwriting — use the other tool for print
OmniCanvas has two free OCR tools, and picking the wrong one wastes your time. The image-to-text tool runs Tesseract, a mature engine built for printed characters. It does its own page layout analysis, handles columns and mixed content, is fast, and is close to perfect on screenshots, typed documents, and clean scans. What it is not good at is handwriting, because the letterforms it was designed around simply do not appear in cursive.
This tool runs the opposite trade. TrOCR is a transformer trained on the IAM handwriting database — real handwritten English, not fonts — so it reads pen strokes that Tesseract cannot. In exchange it is slower, it downloads a much larger model, and it is worse than Tesseract on ordinary printed text, which it was never trained on. If your image is a screenshot, a receipt, a book page, or anything typeset, use the image-to-text tool. If it is a notebook page, a whiteboard scrawl, a filled-in form, or a letter, you are in the right place.
It is also fine to use both on the same page. Many real documents are a printed form with handwritten answers in the boxes; running the printed engine for the structure and this one for the handwritten fields gets further than either alone.
Why handwriting OCR is a fundamentally harder problem
Printed text is a closed problem in a way handwriting is not. A printed 'a' is drawn from a small catalogue of fonts, sits on a predictable baseline, keeps a consistent stroke weight, and is separated from its neighbours by a reliable gap. An OCR engine can segment the page into characters and match each one against known shapes, and forty years of engineering has made that extremely reliable.
Handwriting breaks every one of those assumptions. In cursive there is often no gap between characters at all — the pen never lifts, so where one letter ends and the next begins is itself a guess, and a wrong guess corrupts everything after it. Baselines drift, letters slant differently within the same word, the same person writes the same letter differently depending on what follows it, and ambiguity is genuinely irreducible: an unfamiliar surname written quickly may have several readings that a human would also disagree about.
That is why modern handwriting recognition abandoned character matching entirely. TrOCR reads a whole line as an image and generates the text as a sequence, the way a translation model works — which is what lets it use context to resolve ambiguous strokes. The cost is that when it goes wrong, it goes wrong fluently: it produces a plausible-looking word rather than obvious garbage. Read the output against the original rather than skimming it, which is exactly why every line here is shown alongside the image it came from.
How the page gets cut into lines
A detail that shapes the whole tool: TrOCR reads a single line of handwriting at a time. It has no concept of a page. Hand it a full photo and it will confidently return one sentence and silently discard the rest, which is a failure mode worth knowing about if you have tried other browser-based handwriting tools and wondered where your notes went.
So before any recognition happens, the image is segmented. The page is straightened first — a few degrees of rotation from a hand-held photo is enough to smear the gaps between lines closed — then converted to a black-and-white ink mask using a threshold computed locally for each region rather than one value for the whole page, which is what keeps a shadow across one corner from being read as a giant ink blot. Counting ink pixels in each horizontal row of that mask produces a profile with a peak at every line of writing and a valley in every gap; the peaks become the line boxes. Lines that run together because a descender touches the ascender below are split at the quietest row between them, and stray specks are dropped.
You see the result of all of that drawn over your image before anything is recognized, and you can click any box to skip it. That matters practically: dropping the boxes over a doodle, a margin note, or a page number before you start saves real time, because every line costs a separate inference pass.
How to photograph a handwritten page for the best results
Image quality moves accuracy here far more than it does with printed text, because the model has less redundancy to fall back on. Lay the page flat — a page curling in a bound notebook distorts the letterforms near the spine and is one of the most common causes of a bad result. Fill the frame with the writing rather than capturing the whole desk, and shoot straight down rather than at an angle.
Light the page evenly and from the side, not from directly behind your phone, which produces a hotspot in the middle and shadow at the edges. Avoid casting your own shadow across the page; moving to face a window rather than standing between the page and the window usually fixes this in one step. If the room is dim, more light beats a higher ISO — grain looks like ink.
The ink itself matters. Dark blue or black on plain white or cream paper is ideal. Pencil, especially light pencil, is markedly harder, and so is any writing with low contrast against its background. Heavily ruled or gridded paper can confuse line detection, since a printed rule is ink as far as the segmentation is concerned — the sensitivity slider exists for exactly this case, and nudging it up will ignore the rules while keeping the writing.
Finally, resolution: a modern phone camera at full resolution is more than enough, but a small screenshot of a photo, or an image someone re-shared through a messaging app that compressed it twice, may not be. Use the original file where you have it.
What local processing actually means here
Every tool that claims privacy should be specific about what it does, so: the image you choose is decoded, straightened, segmented, and recognized entirely inside this browser tab. There is no request that carries your picture anywhere. The only thing fetched over the network is the recognition model itself — a set of weight files downloaded from the model host on first use and then cached by your browser, which is the same direction of travel as loading a font.
This matters more for handwritten pages than it does for most OCR. People do not usually handwrite things they intend to publish. Handwritten pages are journals, therapy notes, letters from relatives who have died, medical histories, exam revision, drafts nobody was meant to read, notes from a meeting under NDA. Uploading that to a free web service means a copy exists on someone else's infrastructure, subject to their retention policy, their breach history, and whatever their terms say about training on submitted content. Not making the upload at all is a stronger guarantee than any promise about what happens after it.
The practical consequence is that this tool behaves identically whether the page is a shopping list or something you would never send to a stranger, because it cannot tell the difference and never gets the chance to.
Speed, the model download, and what your device can do
The first run downloads the handwriting model. On a machine with WebGPU — recent Chrome or Edge with hardware acceleration enabled — that is roughly 118 MB of half-precision weights, and a line is recognized in well under a second. Without WebGPU the tool falls back to WebAssembly and downloads a smaller quantized build of about 66 MB, but each line then takes on the order of a second or two of CPU time.
That is why the WebAssembly path only reads the first dozen lines unless you explicitly ask for more: a forty-line page would otherwise be a wordless two-minute wait. Recognition runs on a background thread either way, so the page stays responsive and reports progress line by line, and you can stop it partway and keep whatever has already come back.
The model is cached by your browser after the first download, so returning to this page later starts immediately. Clearing site data clears the model too, and it will download again next time.
Getting the text somewhere useful
Every recognized line is an editable field, so the intended workflow is to read down the list against the thumbnails, fix the handful of words that came out wrong, and delete any line that turned out to be a doodle. What you edit is what gets exported — nothing quietly reverts to the raw recognition.
From there you can copy the whole transcript, download it as a plain .txt file, or send it to an OmniCanvas note, which keeps the lines in reading order as a single block on your canvas. That last path creates the note first and only mentions an account afterwards; copying and downloading need no account at all.