Riyal, Dirham, Rial: Designing the New GCC Currency Symbols Into Your Interface

For years, showing a price in Riyadh or Dubai meant choosing between "SAR 250", "250 ر.س" and "250 AED". None of them felt like a real currency sign, because there wasn't one. That has changed. Saudi Arabia, the UAE and Oman now have official currency symbols, and they are working their way into Unicode, fonts and keyboards.

Most of what I've read about the new signs is written for developers: npm packages, icon fonts, React components. That's useful, but it skips the design questions I deal with on checkout, wallet and dashboard screens for Gulf clients. When should you use the symbol, the ISO code or the Arabic abbreviation? Where does it sit in an RTL layout? And what do you ship while support is still patchy? Here's how I'm handling it.

What changed

The Saudi Central Bank introduced the riyal symbol in 2025, and the Saudi riyal sign was encoded in Unicode 17.0 as U+20C1. The UAE dirham and Omani rial followed. According to the Unicode blog's roadmap post, they arrived in Unicode 18.0 in September 2026, which lists them at U+20C3 and U+20C4. The National covered the dirham's path onto keyboards.

A code point is only the start. A glyph shows up on a user's screen only when their operating system, browser and font all support it. Locale data also matters: CLDR, which most formatting libraries rely on, initially treats the new signs as alternatives rather than the default display. So Intl.NumberFormat will keep printing "SAR" or "ر.س." until you tell it otherwise. Double-check the code points against the official Unicode charts before you hard-code anything.

Symbol, ISO code or Arabic abbreviation?

Having a symbol doesn't mean you should use it everywhere. I decide by context:

• Price tags and product cards: the symbol. Space is tight, the market is obvious, and the symbol reads faster than three letters.
• Cart totals and checkout: the symbol on the amount, with the ISO code once near the total if the product sells in more than one currency.
• Invoices, receipts and anything legal or financial: the ISO code (SAR, AED, OMR), optionally next to the symbol. Precision beats elegance on documents people file or dispute.
• Tables and dashboards with mixed currencies: the ISO code in the column header or a dedicated column, not repeated in every cell.
• Arabic-only interfaces aimed at a broad audience: test the Arabic abbreviation (ر.س، د.إ، ر.ع.) against the symbol. Some users still recognize the abbreviation faster, and that will shift over the next year or two.

The rule that matters: decide once, per context, and document it. Inconsistency is worse than any single choice.

Placement, spacing and bidi pitfalls

This is where most bugs hide. A price is a short string that mixes a number, a sign and sometimes a minus or a range, inside a paragraph that may run right to left.

Which side does the sign go on?

Follow the convention of the interface language and stay consistent. In English layouts, a leading sign (the riyal sign, then "250") mirrors how $ and £ work. In Arabic layouts, many teams put the sign after the number in reading order, which visually places it to the left of the digits. Whatever you choose, put it in the locale settings and not in each designer's head.

Spacing

Use a non-breaking space (or a narrow no-break space, U+202F) between the amount and the sign so they never wrap onto separate lines. On a narrow mobile card, a sign stranded on its own line looks broken.

Isolate the amount

Treat amount plus currency as one unit and isolate it from the text around it. In HTML that means <bdi> or unicode-bidi: isolate. Without isolation, a negative amount or a range like "100–250" inside an Arabic sentence can end up with its minus sign or dash on the wrong side. Test refunds, discounts and ranges specifically, because these are the cases that break.

Western or Arabic-Indic digits

The sign has to sit comfortably next to both ٢٥٠ and 250. Check vertical alignment and weight against both digit sets in your chosen fonts. A sign drawn to match Latin numerals can look heavy next to Arabic-Indic digits. My Arabic typography post covers pairing fonts across both scripts.

Fallback strategy: SVG or glyph?

Right now you can't assume the glyph will render. If it doesn't, users see an empty box (tofu) in the most important place on the screen: next to the price. My approach:

1. Ship an SVG version first, drawn to the official artwork, sized in em so it scales with the text and colored with currentColor.
2. Put it behind one component, so switching to the Unicode glyph later is one change, not a hunt through every screen.
3. Check font coverage for every font in your stack, including system fallbacks on older Android devices. Tools like fc-query or a font inspector will show whether the code point is in the font.
4. Add an accessible label, such as "250 Saudi riyals", because screen readers may not yet announce the new code points correctly.

Libraries like riyal.js show the developer side of this. The design job is making sure the SVG and the glyph look the same, so users never notice the switch.

A Money component spec

Money is one of those things that looks too simple to deserve a component until you count how many ways it's been built in one product. Here's the spec I start from:

Money
  props
    amount        number
    currency      SAR | AED | OMR | USD ...
    display       symbol | code | arabicAbbr
    size          sm | md | lg | display
    tone          default | muted | positive | negative
    showDecimals  auto | always | never
  tokens
    money.gap            narrow no-break space
    money.sign.scale     0.85em (tune per font)
    money.sign.baseline  optical offset per font
    money.negative.color semantic negative
  rules
    amount + sign always isolated (bdi)
    sign position from locale, never hard-coded
    SVG fallback until font coverage confirmed

In Figma, build it with auto layout and a currency property, so designers swap currencies without detaching. In code, the same props map directly to the component. If you've read my post on naming components, you'll notice there's no left or right anywhere in it.

[Waleed: add a screenshot of the Money component and its variants from a recent project.]

QA checklist for e-commerce and fintech screens

• Sign renders on iOS, Android (including older versions), Windows and macOS, with no empty boxes.
• Amount and sign never wrap onto separate lines.
• Negative amounts, refunds and discounts show the minus on the correct side in Arabic and English.
• Ranges and "from" prices read correctly in both directions.
• Sign aligns with Western and Arabic-Indic digits at every text size.
• Screen readers announce the currency.
• Invoices and receipts use the ISO code where required.
• Copy-paste of a price produces something sensible in a spreadsheet.
• Push notifications and emails, which often use different fonts, still render the sign or fall back cleanly.

Closing thoughts

New currency symbols don't come along often, and Gulf users will notice which products adopt them well. The work isn't drawing the sign. It's deciding where it belongs, isolating it from bidi surprises and shipping a fallback that nobody notices. Put those decisions in a component and a checklist now, and the switch to native glyphs later will be a non-event. For the wider set of RTL checks, see my Arabic RTL app design checklist.

Sources: From Central Bank to Code Point: a roadmap (Unicode blog), UAE dirham symbol heads to keyboards with Unicode 18.0 (The National), Using the Saudi riyal symbol in React (riyal.js).

FAQs