Convert WOFF to EOT Online

How to Convert WOFF to EOT Online

1. Upload Your WOFF File: Drag and drop or click "Add Files" to load one or more .woff files from your device. Batch conversion is supported, so you can repackage an entire font family — Regular, Bold, Italic, Bold-Italic — in a single pass. Parsing happens locally using a lazy-loaded opentype.js bundle; nothing is uploaded.
2. Confirm the Output Extension: The output is fixed to .eot (Embedded OpenType) — there are no codec, subset, or hinting toggles on this page because EOT inherits the source font's outlines and metrics directly. If you also need to subset the font to a single language or strip unused glyphs before converting, do that step first with a separate subsetting tool (pyftsubset from FontTools is the common open-source option).
3. Review the File List: The converter wraps the source TrueType/CFF outlines from the WOFF in an EOT container with the application/vnd.ms-fontobject MIME type. Each output file keeps the source font's family name, weight, and style metadata — you do not need to rename it before downloading.
4. Convert and Download: Click "Convert" and save each .eot file individually or grab them as a ZIP. Processing runs entirely in the browser session — no sign-up, no watermark, no file uploaded to any server.

Why Convert WOFF to EOT?

EOT (Embedded OpenType) is a Microsoft container format submitted to the W3C in 2008 but never adopted as a standard — W3C chose WOFF instead. Internet Explorer was the only browser that ever shipped EOT support, and Microsoft retired IE11 on June 15, 2022, after which active EOT usage on the open web dropped to effectively 0%. Despite that, there are still narrow cases where producing an .eot build of a font is the right move:

• Locked-down enterprise intranets running Edge IE Mode — Microsoft has committed to supporting Internet Explorer mode in Edge through at least 2029. Internal SharePoint sites, line-of-business apps, and government portals that target IE Mode still need an EOT fallback in their @font-face rule for the IE compatibility branch to load the font.
• Legacy Windows 10 LTSC and Windows Server desktops — IE11 retirement explicitly excluded the LTSC (Long-Term Servicing Channel) and Windows Server IE11 desktop apps. Kiosks, point-of-sale terminals, and air-gapped industrial workstations on those SKUs may still render webfonts via the IE engine.
• The "bulletproof" @font-face block — The Fontspring bulletproof syntax (still cited in many older CMS themes and WordPress font plugins) lists EOT first to feed IE6–IE8 and IE9 compatibility mode. If you are restoring or migrating a pre-2018 theme that already shipped four-format @font-face blocks, you need the EOT to match what the CSS expects.
• Archival and font-build pipelines — Foundries that historically delivered four-format webfont kits (EOT, WOFF, TTF, SVG) often still publish the full kit for parity. If you are reconstructing a missing format in such a kit, this is the simplest way to do it.
• Reverse-engineering and inspection — Tools like FontForge and ttx (FontTools) accept EOT and can dump the underlying SFNT tables. Converting a WOFF you cannot otherwise open into EOT lets some legacy inspectors read it.
• Embedding fonts in older Office documents and HTML emails — A handful of legacy Microsoft Office and Outlook HTML-rendering paths historically resolved EOT before any other webfont format. This is rare in 2026 but still surfaces in compliance-heavy publishing workflows.

If you are not in one of these cases — for example, you are building a public-facing site in 2026 — you almost certainly want WOFF2 as the primary delivery format and WOFF as a fallback. EOT is genuinely obsolete on the open web, and modern bulletproof @font-face recipes have dropped it. The honest framing for this page is: produce an EOT only when a legacy renderer or build artefact requires it.

WOFF vs EOT — Format Comparison

Where EOT Still Plugs Into @font-face — Bulletproof Syntax Cheat

The classic four-format declaration that still appears in legacy themes:

In a 2026-only stack you can drop everything except woff2 (and optionally woff if you target Safari ≤ 10.x). The EOT lines remain in legacy codebases because removing them without checking IE Mode coverage was historically risky.

Frequently Asked Questions

Do I still need an EOT in my @font-face block in 2026?

Almost certainly not for a public website. Internet Explorer 11 retired on June 15, 2022, and no browser shipping today reads EOT. Strip EOT (and SVG) from your @font-face rule, keep WOFF2 as the primary entry, and add WOFF only if you still need to support Safari versions older than 11. The one exception is enterprise intranets that explicitly target Edge's Internet Explorer mode — that branch still resolves EOT and is supported through at least 2029.

Will the converted EOT preserve hinting, kerning, and OpenType features?

Yes — EOT is essentially an SFNT container with a Microsoft header glued on, so all of the underlying TrueType or CFF tables (glyf, hmtx, kern, GSUB, GPOS, cmap, etc.) carry through untouched. If hinting was present in the source WOFF, it remains present in the EOT, and ligatures and stylistic sets keep working in renderers that read OpenType layout tables.

Why is my EOT roughly the same size as my WOFF?

Because both formats wrap the same underlying SFNT font tables and apply similar compression. WOFF uses per-table zlib (DEFLATE); EOT uses Agfa's MicroType Express, which is also LZ-based. Typical size reductions vs the raw TTF/OTF are around 40–50% for both formats. WOFF2 with Brotli compression is the only mainstream format that dramatically beats both — typically 60–70% smaller than the raw TTF.

Does this converter add MTX compression or a root string for DRM-style URL binding?

No. The output is an uncompressed-but-valid EOT: it wraps the source SFNT in an EOT header with the correct application/vnd.ms-fontobject MIME signature, but does not apply MicroType Express and does not bind the file to a list of allowed URLs (the historical "root string" anti-piracy feature). Every IE version that supports EOT also accepts uncompressed and unbound EOTs.

Why can't I open the resulting .eot in FontForge or macOS Font Book?

EOT is not registered as an installable system font format on macOS or modern Linux desktops — Font Book and the system font picker only accept TTF, OTF, TTC, and dfont. FontForge can import EOT but treats it as a webfont container; for editing, convert the EOT back to TTF first. The EOT format is intentionally a delivery container for IE, not an OS-installable font.

Should I prefer EOT or WOFF for an old IE9-only intranet?

If the intranet truly only ever needs to support IE9, EOT works and was historically the most predictable choice. However, IE9 also supports WOFF 1.0 (added in IE9, March 2011), so a single WOFF file usually suffices and saves you a build artefact. The reason EOT was historically listed first is the IE9 compatibility-mode parser bug, not a hard requirement that IE9 read EOT.

Can I batch-convert an entire font family at once?

Yes. Drop in every weight and style of the family (Regular, Italic, Bold, Bold-Italic, plus any extra weights like Light, Medium, Black) and the converter processes them in one session. The output ZIP keeps the original filenames with the .eot extension swapped in, so your existing @font-face declarations only need a URL extension change, not a filename rewrite.

Are my fonts uploaded to a server?

No. WOFF parsing and EOT writing happen locally in your browser using a lazy-loaded JavaScript bundle. The fonts never leave your machine, which matters for commercial licences that prohibit re-uploading to a third-party converter or font foundry agreements that restrict where the binary may be stored.

What's the difference between EOT and TTF when both are wrapped in the same SFNT tables?

EOT prepends a Microsoft-specific header that includes the font name in UTF-16, a version, a root-string URL list (often empty), and flags indicating whether MTX compression is applied. The actual glyph data after that header is byte-identical to what you'd find in a regular TTF or OTF. Strip the EOT header and you recover the underlying SFNT font. That's also why round-tripping EOT → TTF → EOT typically produces a near-identical file aside from header byte differences.