Stop Making Developers Guess Which Icons to Mirror in RTL

Direction is part of an icon’s behavior.

In right-to-left interfaces, some icons should mirror.

Others should not.

A back arrow usually changes direction.

A checkmark does not.

A reply icon may be directional.

A clock should normally remain unchanged.

A brand logo definitely should not be mirrored just because the interface is RTL.

The problem is that this knowledge often lives in documentation, design files, or simply in someone’s head.

That does not scale.

The fragile approach

A common implementation looks like this:

<Icon
  name="arrow-back"
  className={isRTL ? "mirror" : ""}
/>

Then somewhere else:

<Icon
  name="reply"
  className={isRTL ? "mirror" : ""}
/>

And somewhere else again, another developer has to decide whether an icon should flip.

The same design decision is being made repeatedly.

Eventually, inconsistencies appear.

One screen mirrors an icon.

Another does not.

A third developer is not sure and searches the design system documentation.

The issue is not really RTL support.

The issue is that directional behavior has not been encoded in the icon system.

Put the decision next to the icon

An icon catalog can store more than geometry.

For example:

{
  "name": "arrow-back",
  "directionSensitive": true,
  "mirrorInRTL": true
}

A non-directional icon could instead be:

{
  "name": "check",
  "directionSensitive": false,
  "mirrorInRTL": false
}

The important change is simple:

the application no longer has to guess.

The icon already declares how it behaves.

Direction can be part of the icon contract

We often think of an icon asset as:

name
SVG path
viewBox
size

But production icon systems frequently need more information:

name
geometry
accessibility role
categories
aliases
directional behavior

Once icons are consumed through components, packages, APIs, or generated code, this metadata becomes even more useful.

Instead of writing RTL logic everywhere, the component can handle it centrally:

function Icon({ name, dir = "ltr" }) {
  const icon = catalog[name];

  const shouldMirror =
    dir === "rtl" &&
    icon.mirrorInRTL;

  return (
    <svg
      className={shouldMirror ? "icon-mirrored" : ""}
      viewBox={icon.viewBox}
    >
      {icon.path}
    </svg>
  );
}

Now the rendering layer applies a rule already defined by the icon system.

Not every directional icon is the same

It can also be useful to distinguish between:

directionSensitive

and:

mirrorInRTL

They describe different things.

directionSensitive tells us that the icon has semantic direction.

mirrorInRTL tells the renderer what to do in an RTL interface.

Today, both values may often match.

But separating meaning from rendering behavior leaves room for more advanced cases later.

For example, a design system might eventually use a different asset rather than a geometric mirror.

The metadata should travel with the asset

This becomes especially important when one icon catalog feeds several outputs:

SVG files
React components
Vue components
design system packages
desktop applications
documentation
icon APIs

If RTL behavior exists only in one implementation, every other consumer has to rediscover the rule.

If it belongs to the icon metadata, the same decision can propagate everywhere.

Icon catalog
      ↓
metadata
      ↓
generated components
      ↓
consistent RTL behavior

That is much more robust than relying on tribal knowledge.

A small rule with a large effect

RTL support is sometimes treated as a final presentation detail.

For icons, it can be more fundamental than that.

Some symbols have directional meaning.

That meaning is part of how the icon behaves.

And behavior is exactly the kind of information a mature icon system should encode once instead of asking every developer to reconstruct it.

RTL support is icon metadata, not tribal knowledge.

Direction can be part of the icon contract.