Embed OCR on your site with a widget

You can embed OCR on your site with a ready-made upload widget. Visitors drop a receipt photo, handwritten note, or form scan into an iframe on your page and get text back without leaving for another tab. You create the widget in a Toolsy account, allowlist your domains, copy one iframe that points at /embed/YOUR_ID, and paste it into WordPress, Webflow, Shopify, or plain HTML. This guide walks through when a widget beats a DIY OCR library, how to pick a recognition type, how to paste the embed on common builders, and what to check when uploads fail. Start from Widget for your site. If you need server-side calls from your own backend instead, skim API docs.

Why put OCR on your own page

Sending people to a separate OCR site breaks the job. A bookkeeping portal, agency client site, or survey landing page already owns the visit. Asking someone to open another converter, create an account, and email you the result adds friction and loses context.

An OCR widget embed keeps the upload next to your instructions. The visitor stays on your domain chrome. You choose the recognition type once (handwriting, receipt CSV, form JSON, and similar tools) so every upload uses the same pipeline. Usage counts against your account quota, so you control spend instead of hoping each visitor finds a free online OCR tab.

Search interest for bare phrases like “ocr widget embed” is thin in US Ads data. Product intent still shows up around WordPress OCR, free OCR API, JavaScript OCR, and receipt OCR. Site owners who already know they want an iframe usually look for a paste recipe, not another generic “online OCR” landing.

Agencies and operators also need a path that non-developers can finish. Pasting an iframe into a Custom HTML block is closer to embedding a map or form than shipping an OCR SDK.

What you can try before a hosted widget

You do not always need a hosted embed. Match the path to volume, privacy, and who maintains the page.

Browser-side libraries such as Tesseract.js run OCR in the visitor’s browser. That path avoids sending images to a third party for recognition. It also means you ship model weights, tune languages yourself, and accept weaker results on handwriting, receipts, and messy phone photos. Search volume for Tesseract.js stays meaningful because developers already know the name. For a marketing site that only needs occasional receipt captures, the DIY cost often exceeds the value.

Calling a remote OCR API from your backend gives you full control over storage, retries, and UI. You POST a file, parse JSON, and render your own form. That is the right shape for apps, mobile clients, and workflows that write into a database. It is the wrong shape when a marketer only needs an upload box on one landing page this week.

Built-in phone OCR (Live Text, Lens) helps a single person copy text from a photo. It does not help a stranger on your website. If your audience already photographs notes for personal use, point them at a browser tool such as Convert handwriting to text without an app. If your audience must upload into your flow, stay on the widget or the API.

When Tesseract.js or an OCR SDK is enough

Use an in-browser or SDK path when you already have frontend engineers, you must keep pixels on-device for policy reasons, or you only process clean printed pages. Plan time for packaging, mobile performance, and fallbacks when recognition fails.

Skip DIY when the page owner cannot deploy JavaScript beyond an HTML block, when you need handwriting or receipt structure out of the box, or when you want quota and allowlists managed in one account.

When a pasteable iframe wins

Choose the widget when the job is “put recognition on this URL by Friday.” You get a fixed height upload UI, a domain allowlist, and a recognition type picked at creation time. No API key sits in front-end source. The iframe talks to Toolsy’s embed endpoint; visitors never see your key.

That trade-off is intentional: less custom UI, faster publish, shared monthly quota with direct API calls.

Choose recognition type and allowlisted domains

Before you create anything, decide what the visitor will upload and which hostnames will carry the iframe.

Recognition type is fixed per widget. Toolsy’s account picker includes options such as handwriting to text, receipt to CSV, packing slips, forms to JSON, whiteboard text, notes to Markdown, and related OCR tools. If one page needs receipts and another needs handwriting, create two widgets. You can keep up to ten.

Domains must match the page that hosts the iframe. List example.com and www.example.com if both serve the site. Add preview or staging hosts when your builder uses a different hostname in draft mode. Webflow publish domains, Shopify myshopify.com plus the custom store domain, and Squarespace preview hosts are common misses. If the domain is missing, the embed returns an allowlist error instead of text.

Name the widget for humans on your team (“Client portal receipts”), not for SEO. The visitor sees that name inside the frame.

Match the tool to the photo

Receipts and packing slips belong on table-oriented tools that return CSV-style text. Dense notebook pages belong on handwriting to text. Printed forms with checkboxes and fields fit form to JSON. A mismatch does not crash the widget; it returns messy text that staff then retype.

If visitors shoot phone photos, link your instructions to Phone camera tips for better OCR: flat page, even light, one document per shot, no thumb over the total line.

Build the allowlist before you paste

Write the live hostname first. Add www variants. Add the builder preview host only if editors must test without publishing. Keep the list short. Every extra domain is another place someone can embed your quota-consuming iframe.

When you rotate domains after a rebrand, update the widget in the account before you cut DNS. Old pages with the same embed ID keep working only if the new host is listed.

Create the widget and copy the iframe

Account setup is short. Sign in, open the widgets section, and fill the create form.

1. Enter a name.
2. Pick the recognition type.
3. Paste allowed sites as a comma-separated list.
4. Optionally upload a small logo (PNG, JPG, WebP, or SVG, about 100 KB max).
5. Create the widget, then copy the embed code.

The embed is an iframe. The src looks like https://toolsy.tools/embed/YOUR_ID. Typical attributes are full width, height around 520 pixels, no border, a short title, and lazy loading. Paste the snippet your account shows; do not invent query parameters or JavaScript bridges the product does not document.

Free accounts share a small monthly recognition quota with API calls (40 recognitions). Pro and Plus include a larger trial quota. Paid API plans raise the shared ceiling. Widget traffic and API traffic draw from the same pool, so a busy landing page and a backend job can exhaust the month together.

Open the preview link from the account once before you publish. Confirm the name, logo, and tool label look right. Then paste on a staging page and upload a real sample photo.

Full product overview and pricing context live on the widget page. Use that page when you need the example snippet or plan list; this article stays on the publish recipe.

Install the OCR widget on WordPress, Webflow, Shopify, and HTML

Platform steps differ only in where the HTML block lives. The iframe itself stays the same.

Pick the page that already explains the upload to your visitor. Place the widget under that copy so people see why they are photographing a receipt or form. Avoid burying the iframe in a footer or a modal that mobile browsers clip.

After paste, publish once and test from a phone on cellular data. Many allowlist mistakes only show up outside the editor. Keep a private staging URL if your CMS allows it, then promote the same embed ID to production when the allowlist includes both hosts.

WordPress Custom HTML (no plugin required)

In the block editor, add a Custom HTML block and paste the iframe. In the classic editor, use the Text tab, not Visual, so the editor does not strip the tag. If a cache or security plugin blocks iframes, exclude the page or allow embeds from toolsy.tools.

You do not need an “OCR WordPress plugin” for this path. Search volume for WordPress OCR plugins is low; most site owners only need a place to paste HTML. A plugin still makes sense if you want Media Library batch OCR inside wp-admin. That is a different job from visitor-facing upload on a public page.

Webflow, Shopify, Squarespace, and plain HTML

In Webflow, add an Embed element, paste the iframe, publish, and test on the live URL. Preview domains often differ from production; list both if editors must test in preview.

In Shopify, open Online Store → Pages, add a Custom Liquid or HTML section, paste the iframe, and save. Allowlist both the myshopify.com host and the custom domain. Confirm uploads on the live storefront. Theme editor preview alone is not enough.

In Squarespace, use a Code block. Add both the preview host and the custom domain to the allowlist. On Wix and similar builders, find the HTML / Embed / Code block, paste the iframe, and publish from the production URL.

On plain HTML or a static site, drop the iframe anywhere the layout allows a ~520px tall block. Responsive width (width="100%") is enough for most layouts; adjust height only if your theme clips the result textarea.

Test uploads and fix common embed errors

After publish, open the page in a private window as a visitor would. Upload a clear JPG or PDF the recognition type expects. Wait for the Recognize action to finish. Copy the text out of the result box and check totals, names, and line breaks against the photo.

Run one happy path and one failure path. Happy path: a sharp single-page sample that matches the tool. Failure path: a blank or wrong file type so you see how the UI reports problems. Note the exact error string; support tickets go faster when you can quote origin_not_allowed or a quota message.

If you see a message that the site is not on the widget allowlist, the Origin of the parent page is missing from the domain list. Fix the list in the account; do not swap the iframe ID hoping for a different result. If you see a monthly limit message, the shared quota is exhausted. Pause campaigns, raise the plan, or move heavy batch work to off-peak API jobs. Rate-limit messages mean too many requests in a short window; wait and retry.

Watch usage in the account after a soft launch. A public page can burn through a free sandbox faster than an internal portal. If traffic spikes, point staff at a temporary “email the photo” fallback until quota resets or you upgrade.

Check photo quality before you blame the embed

Blur, glare, and multi-page stacks produce empty or garbled text even when the iframe is healthy. Retake the photo with the page flat and fully in frame. One document per upload beats a collage of four receipts.

For handwriting samples, compare proper nouns to the paper the same way you would after a one-off browser conversion. Unclear strokes may need a human pass.

Confirm branding and layout

A small “Powered by Toolsy” line sits at the bottom of the embed. The block itself stays otherwise neutral. If your design needs a logo, upload it when you create the widget rather than overlaying CSS on the iframe (you cannot restyle the inner document from the parent page).

If the iframe looks cropped, increase the height attribute or give the parent section more vertical space. Horizontal scroll usually means a theme constraint on iframes; set width="100%" and avoid fixed pixel widths below the content width.

Privacy when visitors upload through your widget

Visitor uploads through an embed still leave your site and reach Toolsy for processing. Treat that like any other file upload field on your product.

Tell visitors what they are sending. Put a short notice near the widget if the page collects receipts with personal data, employee expense photos, or form scans. Prefer samples people would already email to your team. Do not imply HIPAA coverage or medical compliance in marketing copy; Toolsy does not claim that.

Processing follows the same retention pattern as other Toolsy uploads: files are processed for the response and discarded shortly afterwards (typically within about one hour), and uploads are not used to train Toolsy’s own models. Read Is it safe to upload documents online? for the decision tree, and What happens to files after processing? for retention detail.

You remain responsible for what you invite onto the page. If your vertical forbids third-party processors, keep OCR inside your VPC or on-device and skip the widget.

When a server-side API fits better than a widget

Use the API when your app already owns the upload UI, when you must store results in your database, or when automation (n8n, Make, scripts) sends files without a browser. Authenticate with a Bearer key on your server, POST to /api/v1/ocr, and keep the key out of public JavaScript.

The widget and the API share quota and recognition tools, but they solve different publishing problems. Soft rule of thumb: marketers paste a widget; engineers wire the API. For request shapes and language snippets, use API docs. Keep this post focused on the iframe path so it does not collide with the developer API walkthrough.

If you only need a one-off conversion for yourself, open a tool page such as Handwriting to Text instead of embedding anything.

Frequently asked questions

How do I embed an OCR widget on my website?

Create a Toolsy account, open the widgets section, and add a name, recognition type, and allowed domains. Copy the iframe snippet your account generates and paste it into an HTML, Embed, or Custom Liquid block on the target page. Publish, then upload a sample photo from the live URL to confirm the allowlist and quota work.

Do I need a developer to add an OCR iframe?

Usually not. If your page builder accepts raw HTML, you can paste the iframe the same way you embed a map or newsletter form. You need a developer when the builder strips iframes, when you must proxy uploads through your own API, or when you want a fully custom UI instead of the hosted embed.

How is the OCR widget different from the OCR API?

The widget is a ready-made upload form for site visitors inside an iframe. The API is for your backend: you send the file with an API key and handle the JSON yourself. Both share the same monthly recognition quota and the same family of recognition tools. Pick the widget for page embeds; pick the API for apps and automation.

Can I use one OCR widget on multiple sites?

Yes, if every hostname that serves the iframe is on that widget’s allowlist. List each domain when you create or update the widget. You can also create separate widgets (up to ten) when sites need different recognition types or separate usage tracking by name.

Does a WordPress OCR plugin work better than an iframe?

For visitor-facing upload on a public page, a Custom HTML iframe is enough and avoids another plugin to update. A WordPress OCR plugin can still help if editors need batch recognition inside the Media Library or post editor. Those admin workflows do not replace an embed on a landing page where strangers upload receipts or forms.

What happens if the domain is not allowlisted?

The embed refuses the recognition and shows an allowlist error. Add the exact hostname of the page (including www or builder preview hosts) in your account, save, and reload the page. Changing only the iframe height or title will not fix an origin mismatch.

Is visitor data safe when they upload through the widget?

Uploads go to Toolsy for OCR processing, then follow the same short retention pattern as other Toolsy file tools. Read the privacy posts linked above before you collect sensitive scans. Avoid promising industry certifications the product page does not state, and tell visitors what the field is for.

Does the embed show Toolsy branding?

Yes. A small “Powered by Toolsy” line appears at the bottom of the widget. You can add an optional logo in the account create form. You cannot hide the powered-by line through parent-page CSS because the UI lives inside the iframe.

What recognition types can the widget run?

Each widget is locked to one tool from the OCR set available in your account. That set includes handwriting to text, receipt and packing-slip CSV outputs, forms to JSON, whiteboard text, notes to Markdown, and related options listed on the widget page. Create another widget if you need a second type on a different page, since one iframe cannot switch tools for the visitor.

When should I use a free OCR API or Tesseract.js instead?

Use Tesseract.js or another client library when engineers can maintain it and you must keep images on-device. Use a free or paid OCR API from your server when you already have an app UI and storage layer. Use the Toolsy widget when you need a pasteable upload box on a marketing or portal page without shipping OCR code yourself.

For one-off handwriting outside an embed, see Convert handwriting to text without an app. For safer photo capture before any upload, see Phone camera tips for better OCR.