The Period After Your Link Is Not Part of the URL

A period typed after a pasted URL is also a legal URL character, so the address cannot say where the link ends. Renderers that link bare URLs each guess with their own rules. Unicode's UTS #58, approved in February 2026 and reissued in September, now publishes one rule set — and wrapping the link in <…> still removes the guess.

The trouble is old and ordinary. You paste https://example.com/notes at the end of a sentence, type a full stop, and the renderer has to decide whether notes. is the page.

A Wikipedia link ending in (planet) sits inside your own parenthetical, and something has to decide which closing bracket belongs to whom. The editors of the Unicode standard describe the outcome bluntly: "When those links are tested with major products, there are significant discrepancies: any two implementations may terminate the linkification at different places, or not linkify the URL at all."¹

This post follows the mechanism end to end: why a URL has no edges, the character-list rule most readers have met, the five-value property model UTS #58 replaces it with, a 13-sentence test across four renderers, and the places where the new standard still has to guess. The fix at the end is older than all of it.

A URL has no edges

The marks you most often type after a link — period, comma, colon, semicolon, question mark, exclamation mark, closing parenthesis — are all legal characters inside one. RFC 3986, the URI standard, lists the period as unreserved and the rest as delimiters a URL may contain. Nothing in the address itself marks where it stops.

The grammar is short enough to read in full (whitespace condensed):²

unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"
gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
            / "*" / "+" / "," / ";" / "="

So https://example.com/notes. is a well-formed address, and so is https://en.wikipedia.org/wiki/Mercury_(planet). Wikipedia uses exactly that bracketed shape to tell one title from another. A parser that treated every trailing period or parenthesis as foreign would break real pages.

The URL specifications know this and step aside. UTS #58 states it directly: "The specifications that define the URL format don’t specify how to handle link detection, because they are only concerned with the structure in isolation, not when it is embedded within flowing text."³

The authors of RFC 3986 saw the same gap in January 2005. Appendix C, on delimiting a URI in context, warns that "it is important to be able to delimit the URI from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URI."⁴

A bare URL has no edges. Software has to invent them.

Inventing means guessing, and guesses differ. The Unicode editors open their standard with the consequence: "some characters that are often used as sentence-level punctuation in text, such as parentheses, commas, and periods, can also be valid characters within a URL. Implementations often do not behave intuitively and consistently."⁵

The naive approach: a list of characters to drop

The best-known rule comes from GitHub Flavored Markdown: scan to the next space, drop trailing punctuation from a fixed list, and drop closing parentheses that outnumber opening ones. It is short, predictable, and ASCII-shaped — and the written spec and its own reference implementation already disagree about what is on the list.

The spec, version 0.29-gfm, states the list in one sentence: "Trailing punctuation (specifically, ?, !, ., ,, :, *, _, and ~) will not be considered part of the autolink, though they may be included in the interior of the link."⁶ Parentheses get a counting rule: "If there is a greater number of closing parentheses than opening ones, we don’t consider the unmatched trailing parentheses part of the autolink, in order to facilitate including an autolink inside a parenthesis."⁷

That rule is an extension. Plain CommonMark 0.31.2 does not guess at all; it files a bare https://example.com under "These are not autolinks" and renders it as text.⁸ Only the bracketed form is a link there.

GitHub's reference parser, cmark-gfm, implements the trailing rule as a switch in extensions/autolink.c. This excerpt is from the commit at the head of the repository on 2026-10-08:⁹

    case '?':
    case '!':
    case '.':
    case ',':
    case ':':
    case '*':
    case '_':
    case '~':
    case '\'':
    case '"':
      link_end--;
      break;

Count the cases: ten, not eight. The code also drops a trailing apostrophe and a trailing double quote. It handles the semicolon differently, too. The spec excludes a trailing ; only when it resembles an HTML entity such as &hl;;¹⁰ the code drops a lone trailing semicolon as well.

None of this is a bug report. It shows that one vendor's rule, written down carefully, is already two rules in practice.

The deeper limit is the alphabet. "While small, hard-coded sets of characters suffice for an ASCII implementation, there are over 150,000 Unicode characters, many with quite different behavior than ASCII," the UTS #58 editors write.¹¹ An eight-character list says nothing about the ideographic full stop 。 or the ideographic comma 、, the period and comma of Chinese and Japanese prose.

The architecture: five values and a bracket stack

UTS #58 replaces the list with a character property. Every Unicode code point carries one of five Link_Term values — Include, Hard, Soft, Open, or Close — and a stack pairs each closing bracket with its opener inside the current part of the URL. The same rule handles a period and an ideographic full stop.

First, the dates, because they are easy to get wrong. Revision 1, dated 2025-12-29, was marked "This is a draft document."¹² Revision 2, dated 2026-02-02 for Unicode 17.0, is recorded in the standard's own history as "First approved published version."¹³ Revision 3, dated 2026-09-14, was "Reissued for Unicode 18.0.0."¹⁴ Unicode's 18.0 summary page lists UTS #58 with "No significant changes in this version," alongside the headline that "Unicode 18.0 adds 13,007 characters, for a total of 172,808 characters."¹⁵

The rule set has been stable since February. September changed the version number, not the algorithm.

The five values, from the standard's Table 3-2, with code-point counts from the Unicode 18.0 data file:¹⁶¹⁷

The Soft rule is the one that answers the title. In the standard's words: ""Soft" characters are not included in the link, unless they are followed by other characters that would be included."¹⁸ A period followed by a space is punctuation: the period after your link is not part of the URL. A period followed by html is part of a filename.

The data file makes the assignments concrete. Anything it does not list defaults to Hard:¹⁷

# @missing: 0000..10FFFF; Hard
002E          ; Soft    # 1.1       (.)  FULL STOP
3001..3002    ; Soft    # 1.1   [2] (、..。)  IDEOGRAPHIC COMMA..IDEOGRAPHIC FULL STOP
0029          ; Close   # 1.1       ())  RIGHT PARENTHESIS
0028          ; Open    # 1.1       (()  LEFT PARENTHESIS

By our count of that file, the ASCII Soft set is ! " ' , . : ; ? — eight characters, the same length as GitHub's list, with five in common. The other six are where the two rules part ways. The question mark, shared on paper, parts ways too: after a path, UTS #58 reads it as the start of a query, not as punctuation.

The bracket stack is scoped. Within a path, every / clears it; within a query, = and & clear it; a fragment directive such as #:~:text= gets its own row.¹⁹ The stack is capped at 125 entries, which the editors note "is required for security."

Walking three sentences through the algorithm

The termination algorithm reads one code point at a time after the domain, remembering the last position still safely inside the link. Include characters and matched Close characters advance that mark. Soft characters wait without advancing it. A Hard character, or a Close with no matching opener, stops the scan and returns the mark.

That is the whole loop. Three traces show what it does with real sentences — a full stop, a nested parenthesis, and a sentence in Japanese:¹⁹

1) See https://example.com/notes. Next
   /             initiator: path begins, stack cleared
   n o t e s     Include  -> mark moves past "s"
   .             Soft     -> wait; mark stays after "s"
   (space)       Hard     -> stop, return mark
   link = https://example.com/notes

2) (see https://en.wikipedia.org/wiki/Mercury_(planet)).
   /wiki/        "/" clears the bracket stack
   Mercury_      Include
   (             Open     -> push "("
   planet        Include
   )             Close    -> matches "(" on the stack, include
   )             Close    -> stack empty, stop
   link = https://en.wikipedia.org/wiki/Mercury_(planet)

3) 東京の記事 https://ja.wikipedia.org/wiki/東京。次へ
   東 京         Include
   。            Soft     -> wait
   次            Include  -> the waiting "。" is included after all
   へ            Include
   (end)         return mark
   link = https://ja.wikipedia.org/wiki/東京。次へ   (our reading)

The first two are the cases the standard was built for, and its own test file carries lines of the same shape. The third is ours, derived from Table 3-2; no line in the test file covers that exact path.

Trace three is the honest limit. Japanese and Chinese prose puts no space after a sentence, so there may be no Hard character for the link to stop on. The Soft 。 waits, the next sentence starts with a letter, and the letter pulls the full stop — and the following words — into the link.

The standard does not pretend otherwise. Its Security Considerations section allows a higher layer to "alter the bounds of the link resulting from the link detection," and its worked example is Japanese: in ウェブサイトはexample.com です。, with no space before the domain, a product "might move the start boundary."²⁰ That example concerns where a link starts rather than where it ends, but the cause is the same: text written without spaces gives the algorithm no edge to stop on.

Measurement: 13 sentences, four renderers, one test file

On 2026-10-08 we ran 13 sentences through four Markdown renderers. Plain CommonMark linked none of the 11 bare URLs, by design. The three GFM-style renderers agreed with each other on 9 of the 11. All four agreed on both explicit forms — <url> and [text](url) — with no exceptions.²¹

These are libraries used as test instruments, not note apps. The table reports what each one linked on that date; it is not a ranking and not a conformance check. The last column is our reading of the UTS #58 base algorithm.

Versions: commonmark.js 0.31.2; markdown-it 15.0.2 with linkify: true (linkify-it 6.1.0); marked 18.1.0 with default GFM; cmark-gfm through the cmarkgfm 2025.10.22 binding. "—" means not linked.

Three rows carry the story. In row 10, the rules themselves disagree: GitHub's list drops a trailing underscore, while UTS #58 classes _ as Include and keeps it. Row 5 is the same kind of split: every renderer drops the final ?, but the UTS #58 algorithm matches a ? after a path as the start of a query and keeps it, even with nothing after it. In row 8, GitHub's rule and our reading of UTS #58 both run the link through 次へ; only linkify-it stops at the ideographic full stop.

Rows 7 and 9 are the spec-versus-code gap from earlier. By the GFM spec text, the closing " and the plain ; would stay in the link; cmark-gfm drops both, as its source says it will.

Ordinary sentences, by contrast, produced no disagreement among the renderers. Rows 1 through 6 and row 11 came out the same in every renderer that linked a bare URL.

The second measurement used Unicode's own test file, LinkDetectionTest.txt, whose 344 test lines mark each expected link between ⸠ and ⸡.²² We stripped the marks, ran three plain-text linkifiers, and compared spans line by line:²³

curl -sLO https://www.unicode.org/Public/18.0.0/linkification/LinkDetectionTest.txt
# For each non-comment line: remove ⸠ and ⸡, run the linkifier,
# re-insert ⸠ ⸡ around what it found, compare with the original line.
# 2026-10-08 → linkify-it 6.1.0: 236/344 · linkifyjs 4.3.3: 288/344 · Autolinker 4.1.5: 319/344

The totals matter less than where the differences sit. On the file's 210 Wikipedia URLs, the three matched the expected span on 207, 209, and 207 lines. On the four lines headed "Don't match mismatched brackets," none of the three produced the expected span on any line. None of these libraries says it implements UTS #58, so this is not a conformance test; it is a map of where agreement runs out.

The fix that works everywhere: give the link edges

Write the edges yourself. A URL inside angle brackets, <https://example.com/notes>, or inside a Markdown link, [notes](https://example.com/notes), ends exactly where you put the bracket — in plain CommonMark, in all four renderers tested above, and for a person reading the raw file. No detection rule is consulted.

The before and after:

Before — the renderer guesses:
See https://example.com/notes.
(see https://en.wikipedia.org/wiki/Mercury_(planet)).

After — you decide:
See <https://example.com/notes>.
(see [Mercury](https://en.wikipedia.org/wiki/Mercury_(planet))).

CommonMark defines the first form in one line: "Autolinks are absolute URIs and email addresses inside < and >."²⁴ The Markdown cheat sheet gives the same habit as a one-line rule; this post is the reason behind it.

The second form carries a label, which matters once a note leaves the app it was written in. Why [text](url) survives the app covers that portability case in full.

Neither habit is new. RFC 3986 recommended it in 2005: "Using <> angle brackets around each URI is especially recommended as a delimiting style for a reference that contains embedded whitespace."²⁵

When a URL truly ends in a period, escape that one character. UTS #58's own example: abc.com/path1./path2. "would serialize as" abc.com/path1./path2%2E, so the whole address survives detection in running text.²⁶ The general principle, from the termination section: "Exceptional cases (URLs that need to use characters that would terminate) can still be appropriately linkified if those few characters are represented with % escapes."²⁷

UTS #58 also explains why a Japanese or Hindi link pasted from a browser can arrive as a wall of %E6%9D%B1…. UTS #58 notes that "many browsers currently don't put the desired Unicode string onto the clipboard, and instead put an unreadable string there."²⁸ Its minimal-escaping half aims for the opposite: "a minimally escaped URL string between two spaces in flowing text is accurately detected, and a detected URL works when pasted into address bars of major browsers."²⁹

Escape the one character that would end the link. Leave the letters readable.

Trade-offs: what UTS #58 does not settle

UTS #58 is a published, testable rule set, not a guarantee. It leaves the start of a URL out of scope, concentrates on http, https, and mailto links, concedes that no algorithm can match every reader's expectation, and in text written without spaces it can carry a link into the next sentence.

Start detection is explicitly someone else's problem: "the determination of the start of a URL is outside of the scope of this specification; the focus is on the part of a URL extending after the domain name."³⁰ The rules above govern only the path, query, and fragment.

The editors are candid about the ceiling: "It is impossible for a link detection algorithm to match user expectations in all circumstances, given the variation in usage of various characters both within and across languages."³¹

Trace three is that sentence in practice.

Products may also layer their own adjustments on top, and the test files say plainly that they "are not applicable to results that are modified by a higher-level algorithm."²⁰ Two apps can both start from UTS #58 and still end a link in different places — legitimately.

People who handle URLs at scale already work around the gap. A JCDL 2026 paper by Obadage and colleagues "compiled a benchmark dataset consisting of 2,338 manually annotated URLs from 200 arXiv papers."³² Their regular-expression pipeline "removes trailing punctuation introduced by prose," and the prompt for their language-model extractor says: "Remove trailing punctuation (like periods or closing parentheses) that are not part of the actual web address."³³

The problem predates language models. A 2014 PLOS ONE study of reference rot by Klein and colleagues reported that converting arXiv PDFs to XML "led to challenges for the URI extraction process such as the recognition of URIs that were separated by a newline in the PDF."³⁴ Neither paper measures how often punctuation breaks links in everyday notes; both show it is a known contaminant that careful people strip by hand.

Two neighbouring cases have their own posts. The CommonMark edge cases that break editors covers flavour differences more broadly, and linking to a specific sentence explains the #:~:text= fragments that UTS #58 gives a row of their own.

Frequently Asked Questions

The questions below are drawn from real searches and long-running forum threads about broken links in plain text. Each answer stays inside what the cited standards and our two measurements show, and none describes how any particular note app behaves — that depends on each app's own detection rule.

Can . (period) be part of the path part of an URL?

Yes. RFC 3986 lists the period as an unreserved character, legal anywhere in a path. That is exactly why a full stop typed after a link is ambiguous: the address grammar allows it, so a renderer must guess whether you meant the end of the sentence or the end of the filename.

Why does my link include the period at the end of the sentence?

Because the renderer's detection rule decided the period belonged to the URL. GitHub's rule drops a trailing period, and under UTS #58 a period followed by a space is Soft and excluded. Rules differ elsewhere, so the reliable fix is to write the link as <https://…> or [text](https://…).

How to escape parentheses in github markdown?

Percent-encode them as %28 and %29, or put the URL inside a Markdown link, [text](url), or angle brackets, <url>. For a bare URL, GitHub's rule keeps balanced parentheses and drops closing ones that outnumber opening ones, so Mercury_(planet) usually survives — but only by count, not by pairing.

How do I paste a URL in a note so it doesn't break?

Wrap it: <https://example.com/page>, or give it a label with [page](https://example.com/page). In our 13-sentence test, both explicit forms produced the same link in all four renderers, including plain CommonMark, which does not link bare URLs at all. RFC 3986 recommended angle brackets in 2005.

Why does a non-English URL turn into percent signs when I paste it?

Many browsers copy the percent-encoded form of the address rather than the readable Unicode text, as the UTS #58 editors note. The link usually still works, but it is illegible. UTS #58's minimal-escaping rules aim to escape only the characters that would break detection, leaving letters in any script readable.

Does UTS #58 fix links in Chinese and Japanese text?

Partly. It recognizes the ideographic full stop and comma as Soft, which no ASCII list does. But when a link is followed directly by more text with no space, our reading of the base algorithm runs the link into the next sentence. The standard allows products to adjust such boundaries at a higher level.

Is UTS #58 a new standard?

It is recent but not brand new. A draft appeared in December 2025; the first approved version was published in February 2026 for Unicode 17.0; it was reissued for Unicode 18.0 in September 2026 with no significant changes. It describes link detection for http, https, and mailto links and makes no claim about any product.

Detection rules will keep improving, and they will keep disagreeing at the margins. Two angle brackets end the argument before it starts.

mnmnote.com keeps your notes as open Markdown files on your own device — so the brackets you type travel with the note to every reader that opens it.