Base44 in Hebrew: building a right-to-left app, and fixing what breaks

The short version

Yes, you can build a Hebrew app on Base44. It builds standard React apps, the text is whatever you write or ask for, and you can edit every file in the Code tab. What Base44 doesn’t do is document right-to-left layout for apps. As of October 2026 its documentation mentions right-to-left languages only for presentations, and Hebrew isn’t among the languages it lists for the editor and AI chat.

So whether a Hebrew app reads correctly comes down to the code the AI writes. The same few problems show up again and again: a layout that flips only halfway, punctuation that jumps to the wrong end of a sentence, arrows pointing the wrong way, scrambled phone numbers and prices, and form fields that fight the text typed into them. Each has a small, well-documented fix, and they’re below. The last section covers what changes when the code is in a repository you own.

What Base44 documents about language and Hebrew

As of October 2026, from Base44’s own documentation:

• The editor. The support page says the platform and the AI chat are available in multiple languages, “including English, German, Spanish, French, Japanese, and Portuguese”. Hebrew isn’t on that list. Human support works in English only.
• The page language. Your app’s index.html sets a lang attribute, and Base44’s SEO documentation tells you to change it in the Code tab to match the app’s main language. For Hebrew that’s lang="he". The same page doesn’t mention the dir attribute that sets direction.
• Sign-in pages. Base44 creates login, registration and password-reset pages inside your app, and its login documentation says you can translate them into any language.
• Emails. You can customize the built-in emails, such as password reset and email verification, on the Builder plan or higher. Your own version of the verification email needs a custom email domain, must show the code, and is reviewed first (Designing emails).
• Fonts. The Theme panel lets you pick a font or upload your own: TTF, OTF, WOFF or WOFF2, up to 5 MB (Customizing the design). You can also add a Google Fonts embed snippet through your layout (Design foundations). When you import from Figma, only Google Fonts are fully supported and other fonts are swapped for a default (Importing from Figma).
• Right to left. The one mention is in the FAQ for presentations: you can ask the AI to translate a presentation, and “languages that read right to left are supported”.
• Translating costs credits. The credits page gives “translate the whole app” as an example of a change that can use several credits, because the AI has to go through many files.

Under the hood, Base44 apps use React, Vite, Tailwind CSS and the shadcn/ui component library (tech stack). That matters, because each of those has its own documented way of handling right-to-left.

Start the app right to left

Most RTL bugs come from an app that was built left to right and translated later. If the app is Hebrew from the start, say so in your first prompt, and be specific. For example:

This app is in Hebrew only and reads right to left.
- Set lang="he" and dir="rtl" on the <html> element in index.html.
- Use logical Tailwind classes (ms-, me-, ps-, pe-, start-, end-, text-start, text-end), never ml-, mr-, pl-, pr-, left-, right-, text-left or text-right.
- Use a font that includes Hebrew letters.
- Mirror arrows and chevrons that mean "back" or "next".
- Show phone numbers, emails and URLs left to right.

The W3C’s guidance is to put dir="rtl" on the html element and not to set the base direction with CSS (W3C: structural markup and right-to-left text). Since Tailwind v3.3, utilities like ms-3 and pe-4 style the start and end of an element, so the same class works in both directions (Tailwind CSS v3.3).

For the font, pick one that actually contains Hebrew letters. Google Fonts lets you filter by Hebrew. A font without Hebrew glyphs doesn’t fail visibly: the browser quietly falls back to another font for the Hebrew text, and your headings end up in two typefaces.

The RTL problems AI-built apps usually have, and the fixes

The layout flips only halfway

What you see: text is right-aligned, but the sidebar is still on the left, icons sit on the wrong side of their labels, and padding is lopsided.

Why: either dir="rtl" is missing, or the components use physical classes (ml-4, pl-2, left-0, text-left, rounded-l-md). Physical classes mean “left” whatever the direction.

Fix: set dir="rtl" on <html>, then replace physical classes with logical ones: ml- becomes ms-, pr- becomes pe-, left-0 becomes start-0, text-left becomes text-start. Avoid “fixing” order with flex-row-reverse: it changes what people see but not the order in the code, so keyboard and screen-reader order no longer match the screen.

shadcn/ui documents its own RTL support, including a DirectionProvider and a migrate rtl command that converts physical classes to logical ones. Try it on a copy or a branch first.

Punctuation and English words land in the wrong place

What you see: a full stop after an English brand name jumps to the start of the line, “(Pro)” comes out as “)Pro(“, or a user’s English name breaks the sentence around it.

Why: the browser’s bidirectional algorithm decides where neutral characters like punctuation and digits go based on the text around them.

Fix: wrap every opposite-direction phrase in its own element. For text you know in advance, use a span with dir. For text you don’t, such as names, product titles or anything from the database, use <bdi> or dir="auto", as the W3C’s guide to inline bidi markup recommends:

<p>ההזמנה של <bdi>{order.customerName}</bdi> התקבלה.</p>
<span dir="ltr">Acme Ltd.</span>

Arrows and icons point the wrong way

What you see: a “back” arrow points left in a Hebrew interface, or “next” in a carousel points backwards.

Fix: mirror icons that show direction of movement or reading order (back, next, chevrons in breadcrumbs, progress), and leave the rest alone. Apple’s right-to-left guidelines put it well: flip controls that follow reading order, keep a control that refers to an actual direction pointing that way, and don’t flip photos or illustrations. In Tailwind, rtl:-scale-x-100 or rtl:rotate-180 on the icon does it.

Numbers, prices, dates and phone numbers

What you see: a phone number shows up as 4567-123-050, the ₪ sign ends up on the wrong side, or a price range reads backwards.

Why: Hebrew uses the same digits as English, and the digits inside a number never reverse. The problems come from the separators around them: dashes, slashes, plus and minus signs.

Fix: format money and dates with the browser’s Intl API, which knows Israeli conventions: new Intl.NumberFormat('he-IL', { style: 'currency', currency: 'ILS' }) (MDN). Wrap phone numbers, card endings, order numbers and URLs in <span dir="ltr">. Progress bars and sliders should run right to left, while the numbers on them keep their normal order.

Forms

What you see: typing an email address into a right-to-left field makes the cursor jump around, and the @ lands in odd places.

Fix: keep labels and help text right to left, but give email, URL, phone and password fields dir="ltr". For free-text fields that may hold either language, use dir="auto", which picks the direction from the first strong character typed. Translate validation and error messages too, including the ones your code shows from the server, which often arrive in English.

Components that set direction in JavaScript

Date pickers, carousels, charts and sliders often calculate positions in JavaScript and ignore dir. shadcn’s RTL page names the Calendar, Pagination and Sidebar components as ones older projects have to migrate by hand. Open each of these in the preview and click through it before you publish.

A check before you publish

1. <html lang="he" dir="rtl"> in index.html.
2. Search the code for ml-, mr-, pl-, pr-, left-, right-, text-left, text-right and flex-row-reverse. Each one should have a reason.
3. Every arrow and chevron points the way the reader moves.
4. Names, emails, phone numbers and prices from the database display correctly inside Hebrew sentences.
5. Tab through each page: focus should move from right to left and top to bottom.
6. Sign-in, registration and password reset pages, and the emails behind them, are in Hebrew.
7. Check on a phone as well as a desktop browser, since menus and dialogs often have a separate mobile layout.

What changes when you own the code

None of these fixes needs you to leave Base44. You can apply them through the AI chat or in the Code tab, and then publish. The limit is that every later AI edit can bring a text-left back, and checking for that is a manual job.

With the code in a repository you own, the check can run on its own. You can add a test that fails the build whenever a physical class appears, run shadcn’s migration on a branch, and write the rules (“logical classes only, <bdi> around user text”) into the instruction files coding agents read, so Claude Code or Cursor follows them on every change.

That’s what moving with Unbase44 gives you. The app’s own React frontend, with a few small patches listed in docs/MIGRATION.md, goes into your private GitHub repository, along with a Base44-compatible backend and docs written for people and coding agents (README, AGENTS.md, CLAUDE.md). It runs locally with docker compose up, and on Railway, pushing to the main branch deploys it. The free analysis shows what’s in your app before you connect anything: start here. For the wider picture, see running a Base44 app locally and working on a Base44 app with Claude Code or Cursor.