Convert TTF to EOT Online

How to Convert TTF to EOT Online

1. Upload Your TTF File: Drag and drop or click "+ Add Files" to load one or more .ttf files. Batch is supported — drop an entire font family (Regular, Bold, Italic, Bold Italic) in one pass. Files stay in your browser session and are never uploaded to a server.
2. Confirm EOT as the Output: The output extension is locked to EOT on this page — there are no codec, quality, or subset controls because EOT is a thin wrapper around the source SFNT data. The original glyf outlines, hinting, and OpenType layout tables pass through untouched; the converter only writes the EOT header and applies the LZ-based MicroType Express compression that IE 6–11 expects.
3. Review the File List (Optional): Reorder files, remove any you don't want, or add more TTFs to the batch. If you only need a Latin subset to keep the EOT small for an intranet site, subset the source TTF first with pyftsubset (from fonttools) before converting — EOT has no built-in subsetter on this page.
4. Convert and Download: Click "Convert." Each .eot downloads individually, or grab the whole batch as a ZIP. No sign-up, no watermark, no email — parsing runs locally in a lazy-loaded opentype.js worker.

Why Convert TTF to EOT?

TTF (TrueType Font) is the cross-platform desktop standard developed jointly by Apple and Microsoft in the late 1980s and shipped in every operating system since. EOT (Embedded OpenType) is Microsoft's proprietary webfont container, created in 1997 and submitted to the W3C in 2008 — the W3C ultimately rejected it and adopted WOFF instead, so EOT remained Internet-Explorer-only. The format is now deprecated for the open web (Microsoft retired the IE 11 desktop application on June 15, 2022) but is still required in a small set of legacy and contractual scenarios.

• Legacy intranets running IE mode — Enterprises with Windows-based line-of-business apps that depend on ActiveX or older Trident rendering still use IE Mode inside Microsoft Edge. Microsoft has committed to supporting IE Mode through at least 2029, and pages running in that mode honor format("embedded-opentype") font entries.
• Maintaining pre-2014 sites under contract — Marketing properties, kiosk apps, and digital-signage builds locked to a specific browser baseline (IE 8/9/10/11) need an EOT entry in the @font-face src list before woff/woff2 for legacy Trident to pick it up. The bulletproof four-way @font-face stack (EOT → WOFF2 → WOFF → TTF) is still in production on plenty of older sites.
• Air-gapped or kiosk environments — Government, industrial control, and ATM-style kiosks frequently run pinned Windows builds with IE 11 (or IE Mode) because re-certifying the entire stack on a modern browser is cost-prohibitive. EOT is the only webfont format those browsers accept.
• Compliance with bulletproof @font-face templates — Older brand-guideline PDFs, CMS themes (early Drupal/Joomla packs), and email-builder templates often hard-code the EOT entry. Generating the file lets you ship the asset without modifying the template.
• Font-licensing artifacts — A handful of mid-2000s commercial EULAs explicitly licensed "EOT for IE distribution" as a separate grant. If your contract names EOT as the distribution format, you need the file even if your traffic shows no IE share.
• Format completeness for asset libraries — Design system docs, brand asset bundles, and font-distribution archives often ship the full set (TTF, OTF, WOFF, WOFF2, EOT) so downstream consumers don't have to ask. Generating EOT once and storing it alongside the others future-proofs the package.

For brand-new public sites, you almost certainly don't need EOT — see the comparison below. If you're starting fresh in 2026, ship WOFF2 with an optional WOFF fallback and skip EOT entirely. Use TTF to WOFF2 for the modern primary, or TTF to WOFF for the broader-compatibility fallback.

TTF vs EOT — Format Comparison

Which Webfont Format Should You Ship in 2026?

A "bulletproof" four-way stack (EOT first to defeat IE9 compat mode, then WOFF2, WOFF, TTF) is still occasionally shipped — but for ~99.7% of 2026 public-internet traffic, a single format("woff2") line is enough.

Frequently Asked Questions

How do I reference an EOT file in CSS for IE 6–11 compatibility?

Use the bulletproof @font-face syntax that defeats IE9's "compatibility view" parser:

@font-face {
  font-family: "Inter";
  src: url("inter.eot");
  src: url("inter.eot?#iefix") format("embedded-opentype"),
       url("inter.woff2") format("woff2"),
       url("inter.woff") format("woff"),
       url("inter.ttf") format("truetype");
  font-weight: 400;
  font-style: normal;
}

The first src (without format()) is the IE9-compat-mode entry; the ?#iefix query string on the second entry tricks IE9 into parsing the rest of the list. Modern browsers ignore the EOT entry because they don't recognize format("embedded-opentype").

Do I still need EOT in 2026?

Almost certainly not for a public-facing site. Microsoft ended IE 11 desktop support on June 15, 2022, caniuse.com reports EOT global usage at ~0.27%, and every browser released since 2014 (Chrome 36+, Firefox 39+, Safari 12+) supports WOFF2 directly. You only need EOT if you're (a) maintaining a pinned legacy intranet that still renders in Trident or Edge IE Mode, (b) honoring a contract that explicitly names EOT, or (c) building a complete font-distribution archive for downstream consumers.

Does the EOT preserve hinting, kerning, and OpenType features from my TTF?

Yes. EOT is a wrapper around the same SFNT data your TTF contains — the converter writes an EOT header in front of the existing tables and optionally compresses the result. The glyf, head, hhea, hmtx, kern, GSUB, GPOS, and name tables are preserved byte-for-byte, so kerning pairs, ligatures, stylistic sets, and TrueType hinting all carry through. The only thing EOT doesn't meaningfully support is variable-font axes, because IE 6–11 predates the variable-font CSS spec.

How large will the EOT be compared to the source TTF?

Roughly similar — EOT's MicroType Express LZ compression typically shaves 10–30% off the SFNT payload, similar to gzip on a TTF. That's substantially worse than WOFF2's 30–50% Brotli reduction. For a 180 KB TTF, expect the EOT to land in the 130–160 KB range. If size matters, subset the source TTF with pyftsubset first to strip glyphs your site doesn't actually use — that has more impact than compression at the container level.

Will Edge or Chrome render my EOT files?

No. EOT support was never added to Microsoft Edge (the Chromium-based replacement for IE), Chrome, Firefox, Safari, or Opera. The only modern way to render an EOT is through Edge IE Mode, which renders eligible sites with the Trident engine for backward compatibility. Microsoft has committed to IE Mode through at least 2029 — after that, your EOT files become unrenderable in any officially supported browser.

What's the ?#iefix hack and why does the bulletproof syntax need it?

IE9's compatibility-view parser has a bug: when it hits a format() token inside an @font-face src list, it stops parsing the whole declaration and falls back to the first src entry. The ?#iefix query string makes IE9 treat the second url() as already-loaded (because it matches the first src URL with a query suffix), letting the rest of the list be parsed by modern browsers without breaking IE9. It's a 2009-era hack popularized by Paul Irish's "bulletproof @font-face syntax" post and Fontspring's updated version.

Is the conversion lossless? Can I round-trip TTF → EOT → TTF?

The conversion is lossless in the sense that no glyph data is altered. You can extract the embedded SFNT back out of an EOT (the inverse direction is supported as EOT to TTF), and the round-trip preserves outlines, hinting, and OpenType tables. What does not round-trip is the EOT-specific metadata: the original TTF didn't have RootString or EOTSize fields, and once stripped on the way back they're gone. For most uses that's fine — you only care about glyph fidelity.

Is my font ever uploaded to a server?

No. The conversion runs entirely in your browser via a lazy-loaded JavaScript worker (opentype.js handles SFNT parsing and the EOT header is written client-side). Your .ttf file never leaves the browser session, which matters for unreleased fonts under NDA, commercial fonts with restrictive EULAs, and corporate brand fonts. No upload, no server log, no account required.

Can I convert OTF or WOFF to EOT the same way?

Yes — use OTF to EOT, WOFF to EOT, or WOFF2 to EOT. All four sources end up writing the same EOT header around the underlying SFNT data, though OTF (PostScript-flavored, with CFF/CFF2 outlines) historically had patchier IE support than TTF (TrueType-flavored, with glyf outlines) — some pre-IE9 versions only rendered glyf-flavored EOTs. If you're targeting the broadest legacy IE range, convert from TTF rather than OTF.