URLs inside Arabic text

A review link in an Arabic message can have the correct internal order and still be hard to read at its edges. A sentence-ending full stop may sit beside the displayed address, where a reader could mistake it for part of the URL. If a message formatter also includes that full stop in the link target, the problem has moved from presentation into navigation.

Do not diagnose every Latin URL in an RTL paragraph as reversed. First distinguish the URL value, the visible link label and the surrounding Arabic sentence. Put an LTR boundary around a displayed ordinary URL, keep sentence punctuation outside it, and verify the destination independently.

The examples use an architectural review portal sharing drawings for a cedar canopy. Its fixture URL includes a path, query and fragment so the tests cover more than a bare domain:

https://files.example.net/reviews/cedar-canopy?view=notes#materials

A sentence's full stop is not automatically a URL defect#

Arabic prose is read from right to left. A sentence-ending mark at the visual left end can be correct. Its proximity to a Latin address does not, by itself, establish a browser bug.

The reader should be able to identify the complete address and understand which punctuation belongs to the message. If that distinction is unclear, improve the component's boundaries or presentation. Do not move the punctuation to match an English sentence merely because the URL contains Latin letters.

Start with the actual markup:

<p dir="rtl">  رابط مراجعة المواد:  https://files.example.net/reviews/cedar-canopy?view=notes#materials.</p>

Inspect the full sentence in the browser. A Latin-starting URL is not equivalent to a phone number containing spaced digit groups, and this sample should not be presented as evidence that all URL characters reverse. The boundary with the final full stop is the question to review.

The supplied browser behavior in this brief was measured in Chromium 151 on 2026-09-24. Use supported Firefox and Safari versions for your own visual checks rather than assuming those measurements cover every engine or punctuation combination.

Keep the actual query, fragment and punctuation in a reproduction. Reducing the fixture to a domain alone can remove precisely the edge the report concerns.

Keep punctuation out of the destination as well as the label#

Suppose the review page contains a section with the fragment materials. A message builder accidentally includes the sentence's full stop in both the visible URL and href.

Problem

<p dir="rtl">  راجع المواد في  <a href="https://files.example.net/reviews/cedar-canopy?view=notes#materials.">https://files.example.net/reviews/cedar-canopy?view=notes#materials.</a></p>

The destination fragment is materials., including the full stop. It is different from the intended materials fragment, independently of how the sentence displays.

Better

<p dir="rtl">  راجع المواد في  <a dir="ltr" href="https://files.example.net/reviews/cedar-canopy?view=notes#materials">https://files.example.net/reviews/cedar-canopy?view=notes#materials</a>.</p>

The URL element contains the complete URL and no sentence punctuation. Its direction is explicit, and the destination no longer includes the extra character. These are two separate repairs: adding dir would not correct a wrong fragment already stored in href.

You can verify the destination difference without navigating:

const target = new URL(  "https://files.example.net/reviews/cedar-canopy?view=notes#materials");const withSentenceMark = new URL(`${target.href}.`); console.log(target.hash); // #materialsconsole.log(withSentenceMark.hash); // #materials.

The WHATWG URL Standard defines parsing and serialization. A parser can accept a full stop as URL content; it does not know that a copywriter intended it as sentence punctuation.

Do not globally strip trailing punctuation from every saved URL as a repair. A period can legitimately belong to a path, query value or fragment. Preserve the intended value where the message is assembled rather than guessing its boundary afterward.

Put direction on the element that owns the visible URL#

When the anchor's text is the URL itself, the anchor is the natural place for dir="ltr". A plain a element does not gain isolation just because it has an href, and a plain span is not a directional boundary either.

For noninteractive display, use a value wrapper:

<p dir="rtl">  العنوان المحفوظ:  <span dir="ltr">https://files.example.net/reviews/cedar-canopy?view=notes#materials</span></p>

This establishes the known base direction and separates the URL from its surrounding sentence. W3C's inline bidi guidance recommends tightly wrapping opposite-direction phrases and using existing meaningful elements where possible.

Keep the whole displayed URL inside the boundary. Wrapping each slash-separated segment independently creates several directional units where the product intended one address. It also complicates selection and styling without expressing the URL's actual structure.

The Arabic label belongs outside. If the entire label-value string is wrapped with automatic direction, the label can select RTL for that combined content. The existence of a directional wrapper somewhere in the DOM is not evidence that the URL itself has the intended scope.

Likewise, do not force the whole notification LTR. Its Arabic prose, action labels and metadata still follow their own direction. The requirement is local to the displayed address.

A descriptive Arabic link label follows Arabic direction#

Readers do not always need the complete URL in prose. For a message whose purpose is to open the drawing review, a descriptive Arabic label can be clearer:

<p dir="rtl">  يمكنك  <a href="https://files.example.net/reviews/cedar-canopy?view=notes#materials">فتح مراجعة المواد</a>  قبل إرسال ملاحظاتك.</p>

Here the visible link text is Arabic. Leave it in the Arabic sentence's direction. The Latin URL in href does not require forcing that Arabic action label LTR.

This distinction gives the component two valid presentations: a displayed address when users need to inspect or copy it, and a localized action label when they need to navigate. Decide which job the component performs rather than making every link expose its raw destination.

If a design shows both a project title and its URL, those are separate content fields. An unknown-direction title can use automatic direction; the ordinary displayed URL can use its known LTR policy. Avoid one automatic wrapper around the combined title, metadata and address.

Do not add a separate accessible label that hides useful visible information without a reason. Check the link's purpose in context and by keyboard navigation. MDN's anchor reference describes link semantics and the relationship between the element and its destination.

Treat domains, paths, queries and fragments as different data#

A URL has structure beyond the visual punctuation. The slash separates path components, ? introduces the query and # introduces the fragment. These delimiters belong to the address, unlike a full stop supplied by the message template.

The review fixture deliberately includes all three. If your test only compares the host, it can miss a lost review mode or a changed fragment. If it only checks that clicking opens the same site, it can miss navigation to the wrong drawing section.

Inspect parsed components when diagnosing a destination problem:

const reviewUrl = new URL(  "https://files.example.net/reviews/cedar-canopy?view=notes#materials"); console.table({  host: reviewUrl.host,  path: reviewUrl.pathname,  mode: reviewUrl.searchParams.get("view"),  fragment: reviewUrl.hash});

MDN's URL reference explains the parsed properties. This inspection addresses destination structure; it does not determine the correct visual order of a mixed-script label.

Avoid manually shuffling delimiters to make the screen look right. If a displayed fragment appears confusing, fix its rendering context. Moving the fragment text into the query or reversing a path changes navigation semantics rather than repairing presentation.

Also distinguish an absolute URL from a relative application route. If the application accepts relative references, resolving them requires the intended base URL. A URL field advertised as accepting a complete website address should not silently apply an unrelated page base to incomplete input.

Preserve query values instead of repairing them as text#

Arabic search values and punctuation-bearing query values need URL construction rules, not bidi workarounds. Use a URL API to construct the query from its data:

const searchUrl = new URL("https://files.example.net/reviews/cedar-canopy");searchUrl.searchParams.set("q", "مظلة الأرز");searchUrl.searchParams.set("view", "notes"); console.log(searchUrl.searchParams.get("q")); // مظلة الأرزconsole.log(searchUrl.href);

Pass the unencoded query value to searchParams. Do not percent-encode it first and then ask the API to encode it again. MDN's URLSearchParams reference explains its encoding and decoding behavior.

This encoded serialization is separate from direction. Percent-encoding Arabic characters does not establish an HTML isolation boundary, and adding dir does not encode query delimiters safely.

An externally issued share URL may have stricter preservation requirements than one your application constructs. If its signature depends on a particular serialized representation, do not reorder query parameters or decode and rebuild them merely to improve display. Follow the issuing service's contract and keep any shortened display label separate from the supplied target.

When an HTML snippet contains multiple query parameters, escape the attribute correctly for HTML source. That serialization layer is different from the parsed DOM value or a JavaScript URL string. A copied address should follow the product's URL contract, not accidentally contain the literal HTML spelling &.

Arabic path segments remain bidirectional content inside an isolate#

An LTR URL boundary does not force every character inside it to behave like Latin text. A readable URL can include Arabic path segments:

https://files.example.net/reviews/مظلة-الأرز?view=notes

Keep this as its own fixture. Inspect the host, Arabic segment, slashes and query together in the full Arabic sentence. The supplied browser behavior does not enumerate this mixed-script URL's exact visual arrangement, so verify it rather than inventing a textual screenshot.

There are also two representations to distinguish: a human-readable display and the serialized URL used by an API. Parsing this fixture can serialize the Arabic path characters as percent-encoded bytes. That is not the browser reversing or translating the path.

Do not decode an entire URL indiscriminately for display and reuse the decoded text as the destination. Some encoded characters are significant delimiters when decoded, and a readable label is not automatically a safe substitute for the original serialized target.

An override is a stronger operation than isolation. Forcing all characters into LTR order can damage Arabic text within the URL. Do not use it simply because the URL contains Latin syntax around an Arabic segment.

If users need a readable Arabic project name, a descriptive link label may avoid making them interpret a mixed-script raw address at all. Keep the actual destination available through the intended navigation or copy action.

Internationalized domain names need a separate representation policy#

Domain-name internationalization is different from Arabic content in the path. A hostname can have a Unicode presentation and an ASCII serialization; the path and query follow different processing rules.

Unicode IDNA compatibility processing describes domain processing, including the rules relevant to internationalized labels. Do not solve a domain-name issue by reversing characters or removing Arabic letters from the displayed hostname.

Decide what the portal promises to show: the complete serialized destination, a readable representation, or a descriptive project label. Then verify that navigation and copying retain the intended target. A label that omits most of a host is insufficient evidence that the destination is correct.

Do not assume the browser's address bar and a page's anchor text use the same display policy. The address bar is browser UI; the page's text is rendered from your markup and content. Test the component you ship rather than using an address-bar screenshot as proof of its behavior.

For external resources, make the destination understandable enough for the user to assess. Direction markup can separate the displayed URL from Arabic prose, but it does not establish that a lookalike hostname is the intended service. Keep that assessment separate from the bidi repair.

Long URLs need wrapping without changing the target#

A review link can fit on desktop and overflow a narrow notification when a query grows. Isolation handles directional processing; it does not remove the address's intrinsic width.

Start with a wrapping policy for a displayed URL:

.review-url {  overflow-wrap: anywhere;}

Apply the class to the isolated URL anchor. If it sits inside a flex or grid component, inspect whether its containing item can shrink; an appropriate min-inline-size: 0 on that item may also be needed. MDN's overflow-wrap reference describes the text-wrapping operation.

Check the actual component at narrow widths. Wrapping the address changes its visual lines, not its logical URL. A line break chosen by layout is not permission to insert a space into the stored path or to submit the broken line as two links.

Do not insert zero-width characters into the URL string as a quick way to create break opportunities. Those become data if the same string is copied, submitted or used for navigation. Keep wrapping in the presentation layer and inspect copy behavior separately.

A readable action label can also be the better product choice when a long machine-generated URL offers little useful information. If the interface intentionally abbreviates an address, provide the full destination through an appropriate inspect or copy action. Do not set href from the abbreviated label.

For container-level diagnosis, see Arabic text overflow: causes and fixes. The URL's LTR boundary and the component's available width remain separate requirements.

Copy the intended URL, not whatever the label happens to contain#

A “Copy review link” action should return the destination representation the application promises. Its visible label may be Arabic, shortened or wrapped across several lines; none is a reliable source from which to reconstruct the target.

Keep the authoritative share URL separate from display text. A label such as “Open materials review” is not an address, and a shortened host-plus-ellipsis string cannot be used as one.

Likewise, avoid reading the text of the entire Arabic sentence to copy the URL. That can include its label and final punctuation. A text node containing extra invisible directional controls can carry those characters into a copied string, whereas HTML direction attributes do not themselves become URL characters.

Test custom copying and manual selection as separate paths. The brief's browser checks show that logical text order is retained on copy even when visual order differs. A successful paste therefore cannot establish that the original address was readable on screen.

For a copied query or fragment, compare the intended components or exact serialized string according to the product contract. Do not silently normalize an externally issued signed link just to make a test pass. A URL serialization difference and a bidi display difference require different explanations.

Also test dynamic changes. Switching the review section should update the visible address, destination and copy payload together. A component can render the new fragment while leaving a copy action closed over an older share URL.

URL inputs need their own direction and validation policy#

An input that collects a complete resource URL is a separate rendering path from a read-only link. On an RTL page, the URL input can inherit RTL unless it declares otherwise.

<div dir="rtl">  <label for="drawing-resource">رابط ملف المراجعة</label>  <input    id="drawing-resource"    name="drawingResource"    type="url"    dir="ltr"    required    value="https://files.example.net/reviews/cedar-canopy?view=notes#materials"  ></div>

The Arabic label stays outside the control's LTR editing policy. MDN's URL input reference covers its input and syntax-validation behavior.

Test typing and pasting the complete fixture, then editing the query and fragment. Saving a syntactically valid URL does not prove that the resource exists, that the user has access or that the product accepts its scheme. Validation and destination policy are separate from field direction.

Do not make the placeholder Arabic prose at the expense of a clear address example. Keep substantive Arabic instructions in a visible label or associated help text. If an opposite-direction placeholder is a design requirement, test it explicitly without adding hidden formatting characters to the input's value.

The saved confirmation must apply its own displayed-URL boundary. A correctly directed editor does not automatically give a later paragraph or link the same scope.

Check automatic linking and rich-text conversion#

A reviewer may paste a URL into a comment rather than insert it through a dedicated link dialog. The comment editor or message renderer then decides where the address ends. That decision happens before the resulting anchor is laid out by the bidi algorithm.

If automatic linking consumes the final full stop, adding dir="ltr" to its output cannot tell the link detector to choose a different endpoint. Inspect the source comment, the detected link token and the generated href. Keep the character-identification problem separate from the visual-order problem.

For the cedar-canopy fixture, compare a pasted address at the end of an Arabic sentence with the same address inserted through the editor's link dialog. Both should retain the intended materials fragment. If they produce different targets, the failure belongs to the authoring or conversion path, even if it was first noticed in an RTL screenshot.

Do not repair that path with a rule that removes every period or closing bracket found at the end of a link token. Those characters can be legitimate URL content. Prefer structured link insertion where the author can specify the destination separately from prose, and define the link detector's punctuation policy for plain pasted text.

Then inspect what survives saving. A rich-text sanitizer, editor serialization step or read-only renderer can discard a direction attribute or move the URL into a new wrapper. Test the saved and reloaded comment, not just the live editing preview. The final anchor should still own the complete intended visible URL when that is its label.

The same applies when a comment contains several links. Give each displayed address its own boundary, with the Arabic connector text outside. One LTR wrapper around an entire list also changes the context of the connectors and says nothing about whether the list's intended reading order is clear. If the sequence matters, express it with the interface's actual list structure and localized instructions.

For a descriptive Arabic label, preserve that label's direction through conversion instead. A renderer that indiscriminately adds LTR to every anchor because its target begins with a Latin scheme can damage Arabic link text while appearing to fix raw URLs.

Keep a regression fixture for each authoring path your product actually offers: paste, link dialog, edit existing target and save/reload. Their output may converge on the same final HTML, but a test of only the final renderer cannot reveal which earlier path constructed the wrong address.

Debug the rendered link and the actual destination#

Select the URL anchor in DevTools, then inspect these properties together:

const link = $0; // Select the URL anchor in DevTools first.const style = getComputedStyle(link);console.table({  label: link.textContent,  hrefAttribute: link.getAttribute("href"),  resolvedHref: link.href,  dir: link.getAttribute("dir"),  direction: style.direction,  unicodeBidi: style.unicodeBidi});

The attribute and resolved href need not have identical spelling, especially for relative references or serialized Unicode content. Compare them with the intended URL contract rather than reporting every difference as corruption.

Inspect which text is inside the boundary. A link with the correct dir can still contain sentence punctuation in its text or a wrong character in its destination. A computed LTR value on a normal inline span also does not, by itself, prove isolation.

If the source text is unexpected, log its code points and trace the message-building path. An auto-linking library may have guessed the wrong endpoint, or a translation renderer may have moved punctuation into the link. Repair that construction step rather than compensating in a screenshot-only stylesheet.

For the review portal, keep the following fixtures:

Repeat these checks after dynamic rendering and at narrow widths. Record browser versions with the visual evidence. For actual review pages, verify navigation to the intended section as well as the visible URL; the example domain here is only a fixture.

A free Ritla scan can report R024, punctuation rendering at the wrong visual end of Arabic text. Interpret the finding against the sentence's intended reading order, then use nested LTR content inside an RTL page for boundary choices or Arabic text overflow when the displayed address will not fit.