Building Hebrew RTL interfaces that hold up: a practical B2B checklist

Most Hebrew interface bugs are not missing translations. They come from assumptions embedded in the layout: a fixed left margin, an arrow that always points right, a table that scrolls the wrong way, or a date displayed in an American format. In B2B software, where people spend hours working on the same screen, these small failures accumulate into distrust.

This checklist follows a practical implementation order: start with document direction, then work outward through shared controls, data presentation and acceptance tests. Treat direction as infrastructure rather than a collection of local fixes.

1. Direction starts at the document, not a nested div

Adding dir="rtl" to an inner container can fix its text while leaving the surrounding layout inconsistent. It also misses controls rendered through portals outside that container: dropdowns, dialogs, tooltips and context menus.

Set direction on both html and body, and pass it to the component library through its direction provider, such as Radix DirectionProvider. With server rendering, verify that hydration and third-party controls do not overwrite it. Switching languages must update the same source of truth rather than introducing competing local settings.

If you fixed item order with flex-row-reverse, check whether you solved the underlying direction problem or merely hid it at one screen size.

2. Use logical spacing instead of physical spacing

Describe spacing, alignment and borders as start and end, not left and right. In Tailwind, use ms/me instead of ml/mr, ps/pe instead of pl/pr, and text-start/text-end instead of text-left/text-right. In CSS, use margin-inline-start, padding-inline-end, inset-inline and border-inline.

The benefit is one layout that behaves correctly in Hebrew and English without duplicate styles. A lint rule against physical spacing utilities makes the convention enforceable and prevents recurring code-review debates.

3. LTR islands inside Hebrew content

Phone numbers, email addresses, URLs, identifiers, code and invoice numbers remain left-to-right even in a Hebrew paragraph. Without isolation, the browser's bidirectional algorithm can move a plus sign, hyphen, bracket or colon to an unexpected position.

Do not change the whole page direction to solve this. Isolate the value with dir="ltr" and unicode-bidi: isolate. Phone and email inputs should also use LTR direction so the caret and punctuation behave predictably while typing.

<span dir="ltr" style="unicode-bidi: isolate">+972-52-000-0000</span>

4. Forms: error direction matters too

• Place labels above fields rather than alongside them; this reduces directional adjustments and improves mobile readability.
• Reserve space for clear Hebrew validation messages so the form does not jump when an error appears.
• Make keyboard tab order follow visual order. A grid that rearranges columns can silently break it.
• Use inputMode="numeric" for numeric input so users get a suitable mobile keyboard.
• Accept familiar spaces and hyphens in phone numbers, and normalize values for storage rather than forcing an unfamiliar display format.

5. Tables, dates and numbers

Hebrew tables read from right to left, while numerical columns still need consistent end alignment for comparison. Use DD/MM/YYYY for Israeli dates. Mixing American and local formats across reports creates operational errors, not just cosmetic differences.

On a small phone, a wide table is rarely a useful work surface. Convert rows into stacked records with label-value pairs and the relevant actions. A 360-pixel screen should not require horizontal scrolling to understand a record.

6. Icons, animation and direction

Navigation arrows, next/previous controls, slide transitions and side menus are directional and should adapt. Settings, search and user icons are not. Mirroring every icon indiscriminately makes symbols, logos and clocks look broken.

7. Acceptance tests before release

1. Check every screen at 360 pixels and confirm there is no horizontal overflow.
2. Open every dialog and dropdown; verify direction, placement and clipping.
3. Type phone numbers and email addresses, then read the stored values back.
4. Complete each form using only the keyboard, including Escape and Enter.
5. Test at least one critical flow with a screen reader and meaningful Hebrew labels.
6. Compare dates on screen, in Excel and in PDF; all three must use the same format.

Conclusion

A good Hebrew interface is more than an English interface with translated labels. It is a consistent set of decisions about direction, alignment, isolation and formatting. When those decisions live in shared infrastructure, recurring bugs become reliable defaults.