Markdown Links

A Markdown link has two parts: the link text readers see and click, and the destination — a URL, file path, email address, or heading the link points to.

[Link Text](https://example.com)

Example

[MDConvertHub](https://mdconverthub.com)

Output

If you're new to Markdown, the Markdown Basics guide covers the fundamentals before you dig into the different link types.

The most common way to add a hyperlink — text and destination written together.

Visit the [GitHub website](https://github.com).

Output

Best for tutorials, blog posts, and documentation where you only need to reference a URL once and readability matters more than reusing it.

Add optional hover text with a quoted title after the URL:

[MDConvertHub](https://mdconverthub.com "Free online Markdown tools")

Many Markdown renderers pass this title through to the underlying HTML title attribute, where browsers commonly display it as hover text — but this depends on both the renderer and the browser, so don't rely on it as a guaranteed feature. It's optional, and worth using only when the link text alone doesn't fully explain the destination.

Separates the link text from the destination — useful when the same link appears multiple times, or to keep long documents easier to read.

Visit the [documentation][docs].

[docs]: https://mdconverthub.com/docs

Common in README files and long technical guides, since the URL is defined once and reused throughout the document.

Also called autolinks in the CommonMark and GitHub Flavored Markdown specs — a URL or email address wrapped in angle brackets becomes clickable with no custom link text needed.

<https://mdconverthub.com>

Output

Use this when the complete URL matters, such as in source references or public resources readers may want to copy directly.

<support@example.com>

or

[Email Us](mailto:support@example.com)

Selecting either opens the reader's default email app with the recipient pre-filled — common on contact pages and support docs.

Both point to files within the same project instead of a full URL, but they resolve differently.

Relative paths are based on the current file's location:

[Installation Guide](docs/installation.md)
[Parent Guide](../README.md)

Root-relative paths start with / and resolve from the site root, regardless of which page they're on — common for linking between pages on the same website:

[Markdown Lists](/markdown-lists)

Both keep working when a repository is cloned or moved, which is why relative and root-relative links are standard in GitHub projects and documentation sites alike.

Many Markdown platforms generate anchor IDs for headings automatically, letting readers jump straight to a section — but the exact ID format depends on the platform, so it's worth confirming on yours:

[Jump to Installation](#installation)

## Installation

Especially useful in long guides and API docs with many sections. See Markdown Headings for how those anchor IDs are generated.

Wrap an image in link syntax to make it clickable — common for logos, badges, and banners.

[![Logo](logo.png)](https://example.com)

For image syntax without a link, see Markdown Images.

Standard Markdown has no syntax for this — [Text](url) always follows platform default behavior, and there's no target="_blank" equivalent. If your platform allows inline HTML, use an <a> tag instead:

<a href="https://example.com" target="_blank" rel="noopener">Visit Site</a>

Check whether your platform (static site generator, CMS, or documentation tool) sanitizes HTML before relying on this — some strip the target attribute for security reasons.

• Use descriptive link text. Tell readers what they'll find before they click — avoid generic phrases like "click here" or "read more."
• Prefer HTTPS whenever it's available.
• Use relative or root-relative links within a project so they keep working if the repository or docs site moves.
• Keep link text concise — short, descriptive phrases are easier to scan than full sentences.
• Avoid stacking multiple links in one sentence unless they're closely related; it hurts readability.
• Check every link before publishing — URLs, file paths, and heading anchors all break silently, not loudly.

Good

Read the [Installation Guide](/markdown-basics)

Avoid

[Click here](https://example.com)

Before publishing large documentation projects, run them through the Markdown Link Checker to catch broken links and invalid URLs.