---
title: "Markdown link not clickable? Why it stays plain text"
slug: markdown-url-not-clickable
excerpt: "Your Markdown link renders as dead text. Six common causes, from pasted addresses to stray parentheses, each with a rule and a tested fix."
quickAnswer: "This page works through six causes, one section each: a pasted web address, angle brackets with no scheme, a space in the link target, parentheses in the link target, a gap between the brackets and the parentheses, and a link that sits inside backticks. Each section names the CommonMark rule involved and shows a fix, and the closing checklist gives a pandoc command you can run on your own file to check the result."
keyTakeaways:
  - "The first section sets out the link forms that core CommonMark turns into something you can click."
  - "The section on pasted web addresses covers what core CommonMark does with them and what an extension changes."
  - "Angle-bracket links get their own section, built on the spec's own failing examples."
  - "Spaces and parentheses in a link target each get a section with tested fixes."
  - "A numbered checklist near the end runs through every cause, plus a pandoc command to confirm the fix."
publishedDate: 2026-10-20
dateModified: 2026-10-20
author: Bobby Huang
cluster: B
role: post
status: published
faq:
  - q: Why didn't my pasted URL turn into a link?
    a: "The section on pasted web addresses covers this case and the fix that works in core CommonMark."
  - q: "Why isn't <www.example.com> a link?"
    a: "The angle-bracket section explains what that address is missing and quotes the matching spec example."
  - q: How do I link an address with a space or parentheses in it?
    a: "The body has one section on spaces and one on parentheses, each with fixes tested in pandoc."
  - q: Why does a link inside backticks stay as text?
    a: "The section on code spans explains this and when backticks are the right choice."
related:
  - markdown-links-to-local-files
  - markdown-cheat-sheet
  - markdown-syntax-guide
---

You dropped a web address into a Markdown file, or typed something that looked like a proper link. Once rendered, it shows up as flat text, and nothing happens when you click it.

When a Markdown link is not clickable, check for a parse problem first. The text didn't match any link rule, so the parser kept it as words. This page covers six causes, and each one has a fix you can check in a few seconds.

## Link forms core CommonMark turns into links

The first form is the inline link. The words a reader sees sit inside square brackets, and the target goes in parentheses straight after: `[Jane Doe's notes](https://www.example.com/notes)`. The second is the autolink, which is just an address between angle brackets: `<https://www.example.com>`. The spec renders an autolink as a link whose visible text is the address itself.

There's also a reference form, where the brackets hold a label and the target sits on a separate definition line. The [Markdown cheat sheet](markdown-cheat-sheet.md) covers all three. For links that point to other files on your disk, see [linking to local files](markdown-links-to-local-files.md).

Each malformed link in the sections below misses these forms, so it stays text. Everything from here on deals with near misses.

## Cause 1: a pasted web address

Paste `https://www.example.com` into a paragraph and core CommonMark leaves it alone. The spec lists a plain address with no brackets under "These are not autolinks," and its output is the same text inside a `<p>` element.

Pandoc agrees. A test file holding `See https://www.example.com for details.` came out of `pandoc -f commonmark -t html` as a paragraph with no `<a>` element in it.

So why do pasted addresses turn blue in so many places? Many viewers switch on an extension that links bare addresses. Pandoc has one too, called `autolink_bare_uris`, which its manual says "makes all absolute URIs into links, even when not surrounded by pointy braces." Running `pandoc -f commonmark+autolink_bare_uris -t html` on that same test file wrapped the address in an `<a href>` element.

That's the trap. A file can look linked in one viewer and plain in another, because only some of them add the extension. If the link must work under plain CommonMark rules too, wrap the address in angle brackets.

## Cause 2: angle brackets with no scheme

Angle brackets alone don't make a link. For a web address, the text inside has to be an absolute URI, which the spec defines as a scheme, then a colon, then characters that aren't control characters, spaces, `<` or `>`. A scheme is 2 to 32 characters that start with an ASCII letter and continue with letters, digits, `+`, `.` or `-`.

`<www.example.com>` has no scheme and no colon. The spec's matching example, `<foo.bar.baz>`, renders as literal text with the brackets shown as `&lt;` and `&gt;`. Pandoc printed `<www.example.com>` the same way. Add the scheme and it works: `<https://www.example.com>` became a link.

Two more details from the same section:

- Any space between the angle brackets breaks the autolink. The spec's example `<https://foo.bar/baz bim>` stays as text.
- Spaces just inside the brackets, right after `<` or right before `>`, break it too. `< https://foo.bar >` is listed as not an autolink.

## Cause 3: a space in the link target

This one bites inline links that point at file names or paths with spaces. The spec gives a link target two shapes. One is any run of characters between `<` and `>` with no line endings and no unescaped angle brackets. The other is a nonempty run with no spaces or control characters.

So `[Jane Doe notes](https://www.example.com/my notes.md)` fails. `[link](/my uri)`, an example taken from the spec, prints exactly as typed. In pandoc the test line stayed plain text too.

You have two fixes:

1. Wrap the target in angle brackets: `[Jane Doe notes](<https://www.example.com/my notes.md>)`. Pandoc made that a link.
2. Write each space as `%20`: `[Jane Doe notes](https://www.example.com/my%20notes.md)`. Pandoc made that a link as well.

In the spec's HTML output for the bracket form, that space is written `%20`. Pandoc kept a plain space inside the `href` in our test. Either way, the text became a link. Neither form lets the target run onto a second line, since the spec bars line endings in a link target even inside angle brackets.

## Cause 4: parentheses in the link target

Some addresses contain parentheses, such as a page name with a word in parentheses at the end. CommonMark allows parentheses in a bare target only when they're backslash-escaped or form a balanced pair.

- `[Doe page](https://www.example.com/Doe_(band))` has a balanced pair, so it links. Pandoc agreed.
- `[Doe page](https://www.example.com/Doe_(band)` has an opening parenthesis with no partner, so the target doesn't qualify and the whole line stays as text. Pandoc printed it unchanged.

When the parentheses really are unbalanced, CommonMark offers two ways out. Escape the odd one, as in `[Doe page](https://www.example.com/Doe_\(band)`, or switch to the angle-bracket form, as in `[Doe page](<https://www.example.com/Doe_(band>)`. Both became links in pandoc with the target `https://www.example.com/Doe_(band`.

## Cause 5: a gap between `]` and `(`

The spec defines an inline link as link text followed immediately by a left parenthesis. A space between them is enough to break it.

`[Jane Doe] (https://www.example.com)` looks fine at a glance. In a pandoc test with no reference definitions in the file, the line came out as ordinary text, square brackets included. Close the gap so `]` touches `(`.

## Cause 6: the link sits inside backticks

Backticks win. The spec says code span backticks take precedence over every other inline construct except HTML tags and autolinks, and it gives a link inside a code span as an example of something that isn't parsed as a link.

Pandoc turned `` `[Jane Doe](https://www.example.com)` `` into one `<code>` element with the brackets and parentheses intact. That's exactly what you want when you're showing link syntax, as this page does. For a working link, take the backticks off. Fences and code spans get fuller treatment in [our post on code blocks](markdown-code-blocks.md).

## Fix a dead link, step by step

Check these in order, top to bottom.

1. **Look for backticks or a fence.** If the link sits in a code span or code block, move it out.
2. **Look at the shape.** Is it a bare address? Wrap it in `<` and `>`.
3. **Check the scheme.** Inside angle brackets, the address needs a scheme and a colon, such as `https:`.
4. **Hunt for spaces.** In an autolink, write each space as `%20`. In an inline link target, use `%20` or wrap the target in `<` and `>`.
5. **Count the parentheses.** Balance them, escape the odd one with `\`, or use the angle-bracket target.
6. **Close the gap.** `]` and `(` must touch.
7. **Confirm with pandoc.** Render the file using `pandoc -f commonmark -t html deadlink.md` and look for an `<a href` element around your text. If it's missing, the parser never saw a link.

Give an agent that writes your Markdown a short standing rule, for example "Wrap every web address in angle brackets." An angle-bracket autolink is part of core CommonMark, so it doesn't depend on a bare-address extension. Our guide to [writing rules an agent can follow](write-markdown-docs-your-ai-agent-can-follow.md) has more on phrasing.

## Where Sashmark fits

Desktop software named Sashmark is in the making, aimed at people who read and fix Markdown files that coding agents rewrite over and over. It is in development and has not been released. The app itself has no AI features. Work on v1 includes rendering tables, links, code blocks, headings, block quotes and lists live, plus editing right on that rendered page. When something outside the app changes the file, the plan is to reload it and keep your place. See the [planned features](/features), the [help pages](/help) and the [roadmap](/roadmap) for where each part stands.

Keep up with it at [sashmark.com](https://www.sashmark.com/).