Subtitle BOM Tool

The Subtitle BOM Tool adds or removes the UTF-8 byte order mark at the very start of a subtitle file. Paste your captions into the SRT Content box, choose add or remove in the Action menu, and the tool returns the same file with that invisible three-byte marker either prepended or stripped. The output downloads as a .srt file and is otherwise character-for-character identical to what you put in.

The BOM is one of those details nobody thinks about until something breaks. A strict SRT parser or an ingest API sees the marker glued onto the first cue number and decides the file does not begin with a valid index, so the whole upload fails with an unhelpful error. Meanwhile some Windows editors and older spreadsheet-style tools assume the opposite and display a UTF-8 file as garbage unless the BOM is present. Caption houses, QC operators and developers wiring up subtitle pipelines all hit this from both directions, often on the same day.

Under the hood the operation is deliberately minimal. In add mode the tool prepends U+FEFF to the text if you need the marker; in remove mode it matches a single leading U+FEFF at the very start of the string and deletes it. Nothing else in the file is examined - no cue parsing, no re-timing, no whitespace normalisation - so a file that already lacks a BOM comes back unchanged rather than corrupted, and a file with one gets exactly one removed.

Everything happens locally in your browser, so client material never leaves the machine, and because the change is a few bytes at the head of the file the tool responds instantly no matter how long the subtitle track is.

• Both directions in one place: The Action select switches between adding and removing the UTF-8 byte order mark, so you do not need a hex editor or a command-line one-liner for either case.
• Surgical edit: Only a leading U+FEFF is affected. Cue numbers, timecodes, blank lines and the dialogue text are passed through exactly as received.
• Idempotent removal: Running remove on a file that has no BOM leaves it untouched, so it is safe to include as a standard step in a delivery checklist.
• Works on any subtitle text: Because the tool treats the input as plain text, it is equally useful for files you are about to feed into a strict parser and for files headed to a Windows editor that expects the marker.
• Visible result for an invisible byte: You paste into the SRT Content box and get a downloadable .srt back, which lets you verify the fix by re-importing rather than squinting at a hex dump.
• No effect on captions on screen: The BOM is metadata about encoding, not content, so viewers see precisely the same words and timing either way.
• Private and instant: The whole operation runs in the browser with no upload, no queue and no waiting for a server round trip.

1. Click Load sample first if you want a known-good file to experiment with before touching a real delivery.
2. Paste your subtitle file into the SRT Content box, making sure you copy from the very first character so any existing byte order mark comes along with it.
3. Set the Action menu to remove when you are feeding a strict parser, an ingest API or a build script, and to add when a Windows editor or an internal tool has been showing your UTF-8 text as garbage.
4. Run the tool and check that the output begins cleanly with cue number 1 followed by its timecode line.
5. Download the result as a .srt file rather than copying it, because copy-and-paste through some editors will silently drop or reinstate the marker you just fixed.
6. Re-import the downloaded file into whatever previously rejected it to confirm the error is gone before you send the batch.

Example 1 - an ingest API rejecting a valid file. The parser reports that the file does not start with a cue index, because the invisible marker sits in front of the digit 1.

Before (BOM shown here as [BOM])
[BOM]1
00:00:01,000 --> 00:00:03,500
Welcome back to the show.

After (Action: remove)
1
00:00:01,000 --> 00:00:03,500
Welcome back to the show.

Only three bytes were deleted, but the file now satisfies a parser that anchors its first match to the beginning of the string.

Example 2 - a Windows editor showing accents as garbage. Adding the marker tells the editor the file is UTF-8 rather than a local code page.

Before
1
00:00:02,000 --> 00:00:04,000
Grusse aus Munchen.

After (Action: add)
[BOM]1
00:00:02,000 --> 00:00:04,000
Grusse aus Munchen.

The captions themselves are unchanged; the editor simply now knows how to decode them.

• Clears a whole class of import errors: "Invalid subtitle file" messages from ingest tools are often nothing more than a byte order mark, and removing it turns a failed upload into a successful one in seconds.
• Keeps both halves of your toolchain happy: When one tool wants the marker and the next refuses it, you can switch a file between the two states instead of maintaining duplicate copies.
• No hex editor required: Editing the first bytes of a file normally means specialist software or a shell command, and this replaces both with a menu choice.
• Zero risk to the caption content: Because nothing but the leading marker changes, you never need to re-QC the timing or re-read the dialogue after running it.
• Safe to run blindly in a checklist: Removal on a file with no BOM is a no-op, so it can sit in your standard pre-delivery routine without anyone having to check first.
• Confidential files stay put: Nothing is uploaded, so pre-broadcast subtitles can be fixed even under a strict NDA.