Typography is the part of a conversion people notice first when it goes wrong. Here is exactly what is carried over, and the one setting that decides whether your converted page inherits your theme’s fonts or keeps the original ones.
What is read from the source
For every heading, paragraph, button and list, the computed values are captured: font family, font size, font weight, text transform, font style, text decoration, line-height and letter-spacing. These are written to the widget’s own Typography group, so each one stays editable in Elementor rather than being locked in a stylesheet.
Sizes are captured per breakpoint. That matters for fluid type — a heading written as a clamp() expression has no direct Elementor equivalent, so three sampled values are stored (desktop, tablet, mobile) which tracks the curve closely enough for most designs.
The Fonts option: original or site
In the options panel you choose how fonts are handled:
- Keep original typography — every widget gets explicit font settings copied from the source. The page looks like the HTML did, independent of your theme.
- Use site typography — per-widget typography is skipped and Elementor’s Global Typography is referenced instead. Headings pick up your site’s heading font, body text picks up your body font.
Use the second one when you are bringing a section into an existing branded site and want it to match automatically. Use the first when you are reproducing a design faithfully.
Web fonts do not travel
This is the most common surprise. A font family name is just a string — if the source page loaded a font from an external stylesheet, that stylesheet is not carried into WordPress. The widget will say the right family name, but the browser falls back to a system font unless the font is available on your site.
Two ways to fix it: register the font in Elementor (Site Settings, Custom Fonts) or use a theme that already loads it. Do this before you judge the converted result, otherwise you will be looking at fallback rendering and chasing a problem that does not exist.
Heading levels
Heading tags are preserved by default, so an <h2> becomes a Heading widget set to H2. There is also a semantic mode that re-levels the document — useful when you are importing a standalone page whose top heading was an H1 into a page that already has one. Two H1s on one page is an SEO smell worth avoiding.
The complete list — eight properties, and nothing else
Being precise here is more useful than being vague, because it tells you exactly what to expect and what to re-do. A widget’s typography receives: font family, font size, font weight, text transform, font style, text decoration, line height and letter spacing.
Everything else in the CSS text model is not part of Elementor’s typography group and does not transfer — text shadow, word spacing, white-space handling, hyphenation, font-variant, text-indent. If your design leans on any of those, treat them as manual work rather than as conversion failures.
Font family names also get their quotes stripped on the way through, so "Helvetica Neue", sans-serif arrives in a form Elementor’s control accepts rather than as a quoted string it would treat as one odd family name.
Only non-default values are written
Four of those eight are skipped when they hold their default: weight 400, transform none, style normal and decoration none are all left unset rather than written explicitly.
The effect is a typography panel you can actually read. Open a converted paragraph and you see font family, size and line height — the three things that were decided — instead of eight fields where five say “normal”. When something is set, it was set on purpose.
It also means a widget genuinely inherits where it should. A paragraph with no explicit weight keeps inheriting weight from your Elementor global rather than being pinned to 400 forever, which matters the day you change your body font to one whose regular weight is 350.
Site typography writes nothing at all
Worth being exact about, because “use site typography” sounds like it might map values across. It does not. In that mode the typography step returns immediately and no font settings are written to the widget — the widget is bound to your Global Typography and inherits everything.
That is why a section converted in site mode adapts completely to the destination site, and why the same section converted in original mode does not budge when you change your global fonts. Neither is better; they answer different questions. “Make this match my site” wants the first. “Reproduce this design exactly” wants the second.
What you should still check
- Long headings at the mobile breakpoint — approximate fluid type can break a line awkwardly.
- Letter-spacing on uppercase display text; small differences are very visible.
- Line-height on multi-line body copy, especially if the source used a unitless value.
- Whether you actually want per-widget typography at all — switching to site typography often makes long-term maintenance far easier.
- Anything relying on text shadow, word spacing or text indent — those are outside the eight and need re-applying.