SVG Text: Tips for Customizing Typography

Most developers treat SVG text as an afterthought. That is a mistake.

SVG text is not just a styling option. It is a distinct rendering system with its own coordinate model, accessibility requirements, and search indexing behavior that HTML text simply does not share.

Used correctly, it gives you scalable vector text that stays sharp at any resolution, supports curved glyph placement via <textPath>, and remains selectable and crawlable by search engines when embedded inline.

Used incorrectly, it breaks on resize, disappears from screen readers, and adds font-loading failures that shift your entire layout.

This guide covers everything: the core <text>, <tspan>, and <textPath> elements, positioning attributes, CSS and animation, accessibility patterns, and production optimization with SVGO and font subsetting tools.

What Is SVG Text?

SVG text is vector-based text rendered inside an SVG document using the <text> element. Unlike raster text in PNG or JPEG exports, SVG text stays sharp at any resolution because it scales with the viewport, not a pixel grid.

Over 65% of all websites now use SVG imagery, up from 63.3% the previous year (W3Techs, 2025). That growth is driven by scalability, small file sizes, and the ability to style SVG directly with CSS and manipulate it with JavaScript.

SVG text is rendered by the browser’s graphics engine, not the document layout engine. That distinction matters. It means SVG text behaves differently from HTML text in terms of layout, inheritance, and how assistive technologies interact with it.

How Browsers Render SVG Text

Rendering path: SVG text goes through the graphics pipeline, not the CSS box model.

Browsers use the SVG coordinate system to position text, where x and y define the baseline origin, not the top-left corner as in HTML. This is a common source of confusion for developers coming from standard HTML layout.

Text rendering quality also varies by operating system. Windows uses ClearType subpixel rendering, while macOS uses Quartz. The same SVG <text> element can appear visually heavier or lighter depending on which platform renders it, even with identical CSS font properties.

SVG Text vs. HTML Text: Core Differences

SVG text is selectable and indexable when embedded inline in HTML. Convert it to paths in Illustrator or Inkscape, and you lose both of those properties entirely.

What Are the Core SVG Text Elements?

SVG text rendering relies on 3 primary elements: <text>, <tspan>, and <textPath>. Each serves a distinct purpose in the SVG coordinate system, and understanding how they relate to each other is necessary before writing any SVG text at all.

89% of front-end developers now regularly work with SVG (SVGMaker industry survey, 2025). Most of them reach for the <text> element daily, but the <tspan> element is what actually gives them control.

The <code><text></code> Element

The <text> element is the root container for all SVG text rendering. It accepts x and y attributes to set the baseline origin point, along with presentation attributes like font-family, font-size, and fill.

Key behavior: text placed in a <text> element renders on a single line, always. No wrapping occurs unless you handle it manually.

The <code><tspan></code> Element

Purpose: inline repositioning and styling of text segments within a <text> block.

A <tspan> sits inside <text> and accepts its own x, y, dx, and dy attributes. The dy attribute in particular is what most developers use to simulate line breaks, by shifting each <tspan> down relative to the previous one.

D3.js uses <tspan> extensively for axis labels and chart annotations in data visualization projects. It is the most compatible approach for line control across all modern browsers.

The <code><textPath></code> Element

Places text along a custom <path> element. The path must be defined inside <defs> with an id, then referenced via href in the <textPath>.

• startOffset: controls where along the path the text begins
• method: align (default) or stretch to distort glyphs along segments
• spacing: auto or exact for inter-glyph control

Text that exceeds the path length is clipped. No overflow or wrapping occurs.

What SVG Text Attributes Control Position and Layout?

SVG text positioning attributes define where text appears in the SVG coordinate system and how it aligns relative to its anchor point. Getting these wrong is the fastest way to end up with text that looks fine in Figma but breaks completely in the browser.

The Baseline Problem Most Developers Hit

The most common mistake: treating y like a top edge instead of a text baseline.

Set y="0" and your text will render almost entirely above the SVG container. The y coordinate marks where the baseline of the first line of text sits, not where the top of the character sits.

dominant-baseline also has inconsistent support across Chrome, Firefox, and Safari. If you need vertical centering, test across all 3 browsers. The middle value in particular behaves differently in Safari compared to Chrome’s rendering engine.

Using <code>text-anchor</code> for Alignment

The text-anchor attribute controls how text distributes around its x position.

• start: text begins at the x coordinate (default)
• middle: text is centered on the x coordinate
• end: text ends at the x coordinate

Highcharts and D3.js both rely on text-anchor="middle" for centering axis labels dynamically in SVG chart rendering.

How Does SVG Text Styling Work?

SVG text accepts both inline SVG presentation attributes and external CSS rules. CSS specificity rules apply: an external stylesheet overrides inline presentation attributes when specificity is equal or higher. This is not always intuitive for developers used to SVG being “attribute-first.”

SVG Presentation Attributes vs. CSS Properties

SVG text styling uses a mix of SVG-specific properties and standard CSS. Most have direct equivalents, but a few behave differently than expected.

Key differences between SVG and CSS text styling:

• fill: replaces color as the primary text color property in SVG context
• stroke: adds an outline to character glyphs with no CSS equivalent for HTML text
• stroke-width: controls outline thickness, grows inward and outward from the glyph edge
• font-family, font-size, font-weight: behave identically to their CSS counterparts
• letter-spacing: works in SVG but kerning control is more limited than in HTML

CSS applied to <text> via a class selector overrides presentation attributes at equal specificity. In practice, most teams pick one approach and stick with it.

Using Web Fonts in SVG Text

Web fonts loaded via Google Fonts or self-hosted WOFF2 files work inside SVG text through standard @font-face declarations and font-family references.

The catch: if a font fails to load, the browser substitutes a system fallback. That fallback has different metrics, which changes the rendered width and height of the text block. In a tight SVG layout, this breaks positioning.

Font fallback failures are one of the most common SVG text bugs in production. The fix is to always define a specific fallback in your font-family value and test with the network throttled to simulate slow font loading.

What Is the Difference Between SVG Text and an SVG Image of Text?

SVG text rendered via a <text> element is live content. Text converted to paths or rasterized into a PNG or JPEG inside an SVG becomes static image data. These are not interchangeable.

The distinction has real consequences for web accessibility, search engine indexing, and file portability. Knowing when to keep text live and when to convert it to paths is a production decision, not an aesthetic one.

Live SVG Text vs. Path-Converted Text

Live <text> elements:

• Selectable and copyable by users
• Indexed by search engines when inline in HTML (Google Search Central, confirmed)
• Accessible to screen readers with proper ARIA markup
• Dependent on the font being available at render time

Path-converted text (via “Object to Path” in Inkscape or Illustrator):

• Renders identically across all environments, no font dependency
• Invisible to screen readers and search engine text crawlers
• Increases SVG file size, since each glyph becomes a path

Adobe Illustrator exports text as paths by default when saving SVG for print workflows. For web use, that default needs to be changed or the SEO and accessibility value of the text disappears entirely.

When to Convert Text to Paths

Convert to paths when font consistency across environments is the top priority: embedded SVG logos, SVG icons used in email templates, or exported SVG files sent to clients who may not have the specified typeface installed.

Keep text live in SVG in HTML when the content needs to be searchable, accessible, or dynamically updated via JavaScript or a backend data source.

How Does SVG Text Affect Accessibility?

SVG text accessibility depends almost entirely on how the SVG is embedded and marked up. Inline SVG with proper ARIA roles gives assistive technologies full access to the text. An SVG loaded as an <img> src hides all internal text from screen readers entirely.

2,014 accessibility lawsuits were filed in the first half of 2025 alone, a 37% year-over-year increase (Loopex Digital, 2025). SVG content without proper accessible markup is a direct contributor to those gaps, particularly in data visualization and icon systems.

ARIA Patterns for SVG Text

The most reliable pattern for accessible SVG, confirmed across browser and screen reader combinations tested by Deque, is:

• Add role="img" to the <svg> element
• Add a <title> element with a unique id inside the SVG
• Add an optional <desc> element for longer descriptions
• Reference both via aria-labelledby="[title-id] [desc-id]" on the <svg>

For decorative SVGs that carry no meaning, use aria-hidden="true" to remove them from the accessibility tree. Decorative text treated as informative content creates noise for screen reader users navigating by element.

Screen Reader Behavior Across Browsers

The inconsistency problem: not all screen readers handle SVG <text> elements the same way.

NVDA on Windows does not reliably announce <title> content inside SVGs without aria-labelledby explicitly set. ChromeVox reads <title> and <desc> content from inline SVGs. VoiceOver on macOS behaves differently depending on whether the SVG is inline or referenced via <img>.

The safest approach across all combinations is to add a visually hidden sibling element outside the SVG with the accessible description, then reference it with aria-labelledby. That pattern works across all major browser and screen reader combinations tested by Simply Accessible.

WCAG 2.1 color contrast requirements apply to SVG text the same way they apply to HTML text. An accessible color contrast ratio of at least 4.5:1 is required for normal-sized SVG text against its background.

How Does SVG Text Perform in Search Engine Indexing?

Google indexes SVG text when the SVG is embedded inline in HTML. Text inside an SVG loaded via <img src="file.svg"> is not indexed. That single implementation decision determines whether your SVG text content contributes to search visibility or disappears entirely from the crawl.

Text inside an inline <svg> element is indexable by search engines, while text inside an SVG loaded via <img> is not (SiteLint, 2024). For text-heavy graphics like chart labels, D3.js data visualizations, or SVG-based infographics, inline embedding has a direct crawlability advantage.

How Google Handles Different SVG Embed Methods

SVG Links and Googlebot

Google does not follow links inside SVG XML markup. John Mueller confirmed this directly: <a xlink:href=""> elements in SVG are not treated the same as HTML <a href=""> links (Edit Agency / Mueller, confirmed via Screaming Frog crawl testing).

Bottom line: never place navigation links inside SVG markup if organic crawlability matters. Those pages will not receive link equity through SVG anchor elements, regardless of how visible they are to users.

For SVG-based infographics or charts where the text content has actual search value, inline embedding is the correct choice. The alt text on an <img src="file.svg"> is the only fallback available for non-inline SVG, and it is a weaker signal than indexed live text.

What Are Common SVG Text Rendering Issues?

SVG text is not as reliable across browsers as most developers expect. The MDN Web DNA report consistently identifies cross-browser compatibility as the single greatest frustration for web developers working with SVG (MDN, 2025).

The issues are predictable once you have hit them. But before you hit them, they are invisible.

The SVG Text Wrapping Problem

Root cause: SVG 1.1 has no native text wrapping. A <text> element renders everything on a single line regardless of container width.

SVG 2.0 proposes a shape-inside property for text flow inside shapes, but browser support for this remains at 0% across all major engines as of 2025 (Can I Use).

3 workarounds exist in production use today:

• Multiple <tspan> elements with manual dy offsets (most compatible)
• <foreignObject> embedding HTML inside SVG to get native CSS wrapping
• JavaScript libraries like D3.js and svg.js that calculate line breaks dynamically

Cross-Browser Baseline Inconsistencies

Chrome and Safari handle dominant-baseline differently. The middle value in particular produces visually different vertical alignment between the 2 engines.

The subpixel gap: Windows ClearType and macOS Quartz render the same font-weight value with different perceived stroke thickness. An SVG wordmark that looks right on macOS will often appear slightly heavier on Windows.

Testing SVG text on both platforms before shipping is not optional. It is the only way to catch these discrepancies before users do.

How Do You Wrap Text in SVG?

Text wrapping in SVG requires a deliberate implementation decision. The choice of approach affects rendering consistency, accessibility, and export compatibility. No single method works perfectly across all environments.

Using <code><tspan></code> for Manual Line Breaks

The most universally compatible approach. Each line of text becomes a <tspan> with a dy offset that shifts it downward from the previous line.

Standard pattern:

• Set the first <tspan> with an absolute x value
• Set subsequent <tspan> elements with x reset to the same value and dy set to line-height in em or px
• Calculate line break points manually or via JavaScript string measurement

D3.js uses this exact pattern internally for axis labels that exceed a set character width, splitting strings and appending <tspan> elements with computed positions.

Using <code><foreignObject></code> for HTML-Based Wrapping

Insert a <foreignObject> element inside the SVG, then place an HTML <div> or <p> inside it. CSS word-wrap and overflow-wrap handle the wrapping automatically.

Works in all modern browsers. The limitation: <foreignObject> content does not export correctly from SVG editors like Inkscape, and it does not render in some SVG-to-PNG conversion pipelines.

Use it when: the SVG is inline HTML only and will never be exported as a standalone file or converted to raster.

Avoid it when: the SVG needs to render consistently outside the browser, for example in email templates, PDF exports, or server-side rendering pipelines.

How Does <code><textPath></code> Work in SVG?

<textPath> places text along a custom path element defined elsewhere in the SVG. The text flows along the curve, with each glyph rotated tangentially to match the path direction at that point.

The setup requires 3 components: a <path> inside <defs> with a unique id, a <text> element, and a <textPath> child that references the path via href.

Key <code><textPath></code> Attributes

startOffset: controls where along the path the text begins, as a percentage or length value. Set to 50% with text-anchor="middle" to center text on the path.

method: two options.

• align (default): glyphs are placed upright and rotated to follow path direction
• stretch: distorts individual glyphs to fill path segments, rarely used in practice

spacing: auto lets the browser handle inter-glyph spacing; exact forces fixed spacing. Text that exceeds the total path length is clipped with no overflow or wrapping behavior.

Real-World Use Cases for Curved SVG Text

Circular badge text in logos and seals. Radial chart labels that follow arc paths in data visualization. Decorative type treatments on SVG illustrations.

Figma users reach for curved text in Figma during design, then export the result as SVG with <textPath> intact for use in HTML. The path definition transfers cleanly, though font dependencies still apply at render time.

What Are the SVG Text Use Cases in Web Design and Data Visualization?

SVG text is used across 3 broad categories: branding and identity work, data visualization, and interactive elements that require text positioned relative to graphics. Each has different requirements for font handling, animation, and accessibility markup.

D3.js has powered groundbreaking data visualizations for over a decade and is used by organizations including The New York Times, Airbnb, and MTV for SVG-based chart rendering (D3 Observable, 2024). Chart labels, axis annotations, and tooltip text in D3 are all rendered as SVG <text> elements with text-anchor and dominant-baseline controlling position relative to data points.

SVG Text in Data Visualization

SVG Text in Branding and Icon Systems

Logos and wordmarks converted to paths remove font dependency entirely, which is why most SVG brand files you download from a company’s press kit have no live <text> elements.

SVG sprite systems use live text sparingly, usually only for screen-reader labels hidden with aria-hidden. The visual content is path-based. The accessible name is text-based.

Practical split: visual content as paths, accessible labels as live text. That approach gives you rendering consistency and accessibility at the same time.

How Do You Animate SVG Text?

SVG text supports 3 animation approaches: CSS @keyframes, GSAP (GreenSock Animation Platform), and SMIL. Each has specific browser support characteristics and production trade-offs worth knowing before you start building.

94% of UI/UX designers now regularly work with SVG (SVGMaker, 2025). Animation is a core part of that workflow, and most of the complex motion work in production is handled by GSAP rather than pure CSS or SMIL.

CSS Animation on SVG Text

CSS transition and <code>@keyframes</code> work on animatable SVG text properties.

Animatable via CSS on <text>:

• fill and opacity for color and fade transitions
• font-size for scale-in effects
• transform for position and rotation
• stroke-dashoffset combined with stroke-dasharray for the text-drawing effect

The stroke draw effect works by setting stroke-dasharray to the total path length of the text outline and animating stroke-dashoffset from that value to zero. The result looks like the text is being written on screen.

GSAP-Based SVG Text Animation

GSAP’s DrawSVGPlugin controls stroke-dashoffset and stroke-dasharray on <text> elements directly, with both starting and ending positions of the visible stroke segment animatable independently. That is something CSS-only solutions cannot do.

GSAP targets <text> and <tspan> elements with .to() and .fromTo() methods, and handles cross-browser SVG transform inconsistencies automatically. The platform also respects prefers-reduced-motion when configured, which matters for WCAG 2.1 compliance on animated SVG text.

SMIL note: Chrome moved to deprecate SMIL in 2015, then reversed the decision. Support remains inconsistent across browsers. GSAP and CSS are the production-safe choices for SVG text animation in 2025.

How Do You Export and Optimize SVG Text for Production?

Production-ready SVG text requires decisions at 3 stages: export settings in the design tool, file optimization with SVGO, and font handling for rendering consistency. Skipping any one of these leaves measurable performance or quality issues on the table.

SVGO typically reduces SVG file sizes by 30 to 60% by removing editor metadata, comments, redundant attributes, and unnecessary decimal precision (Vectosolve, 2025). For complex files exported from Adobe Illustrator, reductions of 50 to 70% are common.

Export Settings in Inkscape and Adobe Illustrator

Inkscape: use “Save as SVG” to preserve live <text> elements. “Save as Optimized SVG” runs SVGO automatically but may strip <title> and <desc> elements needed for accessibility, depending on plugin configuration.

Adobe Illustrator: the default “Save as SVG” dialog includes an option to preserve text or convert to outlines. For web use, preserve text unless font consistency is the priority. Illustrator exports tend to include more redundant metadata than Figma exports, making SVGO more impactful on Illustrator files.

Always check the viewBox attribute after export. If it is missing or set incorrectly, text positioned with absolute coordinates will break when the SVG scales.

Font Optimization for Embedded SVG Text

Embedding a full font as base64 inside SVG keeps rendering consistent but increases file size significantly. A better approach is subsetting.

Glyphhanger and fonttools subset fonts to only the characters actually used on the page. One developer reduced a 765 KB Roboto file to 56 KB by subsetting to only the characters present on their site (Stefan Judis, 2023). That is a reduction of over 90%.

Production font handling for SVG text:

• Self-host WOFF2 subsets rather than loading full Google Fonts
• Use @font-face with unicode-range to load only the subsets needed per page
• Define specific fallback fonts in font-family to prevent layout shifts when fonts are slow

For SVG optimization in production workflows, run SVGO with multipass: true for maximum file size reduction. Use SVGOMG for a browser-based preview before committing to any plugin configuration that strips <title> or <desc> elements from accessible SVGs.

FAQ on SVG Text

What is SVG text?

SVG text is vector-based text rendered inside an SVG document using the <text> element. It scales without quality loss, stays selectable, and supports CSS styling, stroke outlines, and path-based glyph placement unavailable in standard HTML text.

Is SVG text indexed by Google?

Yes, but only when the SVG is embedded inline in HTML. Text inside an SVG loaded via <img src> is not indexed. SVG used as a CSS background image is never crawled or indexed by search engines.

Can SVG text wrap automatically?

No. SVG 1.1 has no native text wrapping. Long strings extend beyond the container. Workarounds include manual <tspan> line breaks, <foreignObject> with HTML wrapping, or JavaScript libraries like D3.js that calculate break points dynamically.

What is the difference between <code><text></code> and <code><tspan></code>?

<text> is the root container for SVG text rendering. <tspan> is an inline child element used to restyle or reposition text segments within a <text> block, typically via dx, dy, or separate x coordinates.

How do you style SVG text with CSS?

SVG text accepts standard CSS properties like font-family, font-size, and font-weight. Use fill instead of color for text color. CSS class selectors override inline SVG presentation attributes when specificity is equal or higher.

Does SVG text work with screen readers?

It depends on implementation. Inline SVG text is accessible when the <svg> has role="img" and aria-labelledby referencing a <title> element. Without proper ARIA markup, screen reader behavior varies significantly across browsers.

What is <code><textPath></code> in SVG?

<textPath> places text along a custom <path> defined in <defs>. Each glyph rotates tangentially to the curve. The startOffset attribute controls where text begins along the path, as a percentage or length value.

How do you animate SVG text?

Use CSS @keyframes on properties like fill, opacity, and transform. For complex sequences, GSAP targets <text> elements directly. The stroke-dashoffset technique creates a handwriting draw effect by animating the visible stroke segment progressively.

How do you optimize SVG text for production?

Run files through SVGO to remove editor metadata and reduce file size by 30 to 60%. Subset embedded fonts using Glyphhanger or fonttools. Always define a CSS fallback in font-family to prevent layout shifts when the primary font fails to load.

Should you convert SVG text to paths?

Only when font consistency across environments matters more than accessibility and indexability. Path-converted text renders identically everywhere but becomes invisible to screen readers and search engines. For web use, keep text live unless the SVG ships as a standalone file or email asset.

Conclusion

This conclusion is for an article presenting SVG text as a technical system worth understanding fully, not just using casually.

The element, dominant-baseline alignment, textLength` adjustment, and glyph spacing control are not minor details. They determine whether your SVG text rendering holds up across browsers, devices, and screen readers.

Get the accessible SVG markup right and you cover both WCAG compliance and search engine crawlability in one pass.

Subset your fonts with fonttools. Run SVGO on every export. Keep live text in production SVGs whenever indexability and assistive technology access matter.

The decisions made at the element level determine everything downstream. Now you have the specifics to make them correctly.