Why Subtitle Edit Can't OCR Hardcoded Subtitles (And What Works Instead)

Short answer: Subtitle Edit's OCR reads image-based subtitle tracks — VobSub from DVDs, PGS from Blu-rays, and the same tracks muxed inside MKV files. It does not read text that has been burned into the video picture itself. If your MP4 shows subtitles you can't switch off, there is no subtitle track in the file for Subtitle Edit to import, so its OCR tools never get a chance to run. Extracting that text requires a different kind of tool — one that scans the video frames — and this guide covers exactly which tools do that.

This question comes up constantly in the Subtitle Edit community: someone has an .mp4 with subtitles visibly on screen, remembers an "Import/OCR subtitles" menu, and can't work out why nothing happens. The confusion is understandable, because both features are called OCR — but they solve two very different problems. Let's take them apart.

What does Subtitle Edit's OCR actually do?

DVDs and Blu-rays don't store subtitles as text. They store them as images: every subtitle line is a small picture with a timestamp, sitting in its own track next to the video and audio streams. DVD subtitles use the VobSub format (.sub/.idx), Blu-rays use PGS (.sup), and both can be muxed into an MKV container when you rip a disc.

Because those pictures live in a separate track, Subtitle Edit can walk through them one by one, run OCR on each image, and hand you editable text with the original timing preserved. That is what Subtitle Edit's OCR window is for, and it is genuinely good at it: it supports multiple OCR engines and preserves every cue's original timing.

The key point: in every one of those cases, a subtitle track already exists inside the file. Subtitle Edit's OCR converts one subtitle format (pictures) into another (text). It never looks at the movie frames themselves.

Where did the "Import/OCR subtitles from video" menu go?

If you remember an Import/OCR option and can't find it or can't get it to work, here is what it actually did: it looked inside the video container for an image-based subtitle track — for example, a PGS track inside an MKV — and opened it for OCR. It read the container's track list, not the picture.

Run it on a typical .mp4 with burned-in subtitles and it finds nothing, because there is nothing to find: the file contains a video stream, an audio stream, and no subtitle track at all. The text you see on screen is not a subtitle in any technical sense anymore — it is part of the image, no different from a face or a lamp in the background.

Burned-in (hardcoded) subtitles are a different problem

When subtitles are burned in — also called hardcoded — the text was rendered onto the frames at encoding time. Whoever produced the file merged the subtitles into the picture permanently. That has three consequences:

• No track to import. Container tools (Subtitle Edit, ffmpeg, MKVToolNix) all report the same thing: this file has no subtitles.
• No way to switch them off. Players can only toggle tracks; there is no track here.
• Extraction becomes a video-analysis problem. To recover the text, a tool has to scan the actual frames: detect when a line appears and disappears (that becomes your timing), recognize that hundreds of near-identical frames show the same line (so you get one cue, not three hundred duplicates), and separate the text from whatever is moving behind it.

That frame-scanning pipeline is a fundamentally different job from decoding a neatly packaged image track, which is why Subtitle Edit — a subtitle file editor — doesn't do it, and why "OCR" means something different in each context. This isn't speculation: Subtitle Edit's own team has said on GitHub that "hardsubs detection & extraction is not a simple task, so it won't be implemented in SE," and a feature request for video-frame OCR was closed as wontfix.

How to tell which kind of subtitles your video has

A ten-second check in any player that shows subtitle tracks (VLC, IINA, mpv):

1. Open the video and look at the subtitle track menu (in VLC: Subtitle → Sub Track).
2. If a track is listed and you can toggle it off, your subtitles are a real track — embedded, toggleable subtitles. Subtitle Edit can usually extract these directly, and if they are image-based, its OCR handles them.
3. If the menu is empty but subtitles are still on screen, they are burned in. No container tool will help; you need frame OCR.

This one check saves a lot of wasted effort, because the two situations look identical while watching but need entirely different tools.

What actually extracts hardcoded subtitles?

Once you know the text is burned in, these are the realistic options:

Tool	Platform	Price	Workflow
VideoSubFinder	Windows	Free	Multi-step: detect text frames, export images, OCR them separately, rebuild timing
videocr / VideOCR	Windows, Linux	Free, open source	Command line or a simple GUI; single tool, some setup
GeekLink	macOS (Apple Silicon)	Free tier	One pass: drop in the video, select the subtitle area, export SRT with timing

All three read the video frames rather than the container, which is the capability Subtitle Edit lacks. Which one fits depends mostly on your platform and how much manual work you tolerate:

• VideoSubFinder is the veteran Windows workflow. It works, but you assemble the pipeline yourself — frame detection, image OCR, and timing reconstruction are separate stages.
• videocr / VideOCR wraps frame OCR into one open-source tool with official Windows and Linux builds.
• GeekLink is a native Mac app that runs the whole pipeline in one pass, entirely on your machine: scan the video, OCR the burned-in text, and export a clean SRT. It also batch-processes multiple videos and can translate the extracted subtitles in the same run. See the step-by-step guide in How to Extract Hardcoded Subtitles Using OCR.

The workflow that pairs best with Subtitle Edit

None of this makes Subtitle Edit less useful — it just sits at a different stage of the pipeline. The workflow that works well in practice:

1. Extract: run a frame-OCR tool on the burned-in video and export an SRT.
2. Polish: open that SRT in your editor of choice — Subtitle Edit included — to fix recognition slips, adjust timing, and reformat. The output is a standard SRT file, so it opens in any subtitle editor.
3. Deliver: keep the SRT as a toggleable subtitle track, translate it, or burn it back into a new video with different styling.

Prefer to stay inside Subtitle Edit? The workflow its community recommends is running VideoSubFinder first to detect the text frames, then loading those images into Subtitle Edit via File > Import > Images and OCR-ing them there. It works, but a separate frame-detection tool still does the video analysis — Subtitle Edit only takes over once the frames are extracted.

Whatever extractor you use, plan for a proofreading pass. OCR accuracy on burned-in text depends heavily on the font, the contrast between text and background, and how much motion sits behind the subtitle line. The realistic goal is a solid draft that needs light cleanup — not a perfect file straight out of the tool.

Disclosure: GeekLink is our product. We've tried to keep this guide factual and fair — Subtitle Edit is an excellent editor, and the limitation described here is a design choice its own team has confirmed, not a flaw. Use whichever extraction tool fits your platform, and keep editing wherever you're most comfortable.

Frequently Asked Questions

Related Articles