592

Is there markdown syntax for the equivalent of:

Take me to <a href="#pookie">pookie</a>

... 

<a name="pookie">this is pookie</a>
daaawx
  • 2,268
  • 2
  • 12
  • 13
Synesso
  • 34,066
  • 32
  • 124
  • 194

11 Answers11

797
Take me to [pookie](#pookie)

should be the correct markdown syntax to jump to the anchor point named pookie.

To insert an anchor point of that name use HTML:

<a name="pookie"></a>

Markdown doesn't seem to mind where you put the anchor point. A useful place to put it is in a header. For example:

### <a name="tith"></a>This is the Heading

works very well. (I'd demonstrate here but SO's renderer strips out the anchor.)

Note on self-closing tags and id= versus name=

An earlier version of this post suggested using <a id='tith' />, using the self-closing syntax for XHTML, and using the id attribute instead of name.

XHTML allows for any tag to be 'empty' and 'self-closed'. That is, <tag /> is short-hand for <tag></tag>, a matched pair of tags with an empty body. Most browsers will accept XHTML, but some do not. To avoid cross-browser problems, close the tag explicitly using <tag></tag>, as recommended above.

Finally, the attribute name= was deprecated in XHTML, so I originally used id=, which everyone recognises. However, HTML5 now creates a global variable in JavaScript when using id=, and this may not necessarily be what you want. So, using name= is now likely to be more friendly.

(Thanks to Slipp Douglas for explaining XHTML to me, and nailer for pointing out the HTML5 side-effect — see the comments and nailer's answer for more detail. name= appears to work everywhere, though it is deprecated in XHTML.)

Community
  • 1
  • 1
Steve Powell
  • 22,318
  • 7
  • 39
  • 39
110

On bitbucket.org the voted solution wouldn't work. Instead, when using headers (with ##), it is possible to reference them as anchors by prefixing them as #markdown-header-my-header-name, where #markdown-header- is an implicit prefix generated by the renderer, and the rest is the lower-cased header title with dashes replacing spaces.

Example

## My paragraph title

will produce an implicit anchor like this

#markdown-header-my-paragraph-title

The whole URL before each anchor reference is optional, i.e.

[Some text](#markdown-header-my-paragraph-title)

is equivalent of

[Some text](https://bitbucket.org/some_project/some_page#markdown-header-my-paragraph-title) 

provided that they are in the same page.

Source: https://bitbucket.org/tutorials/markdowndemo/overview (edit source of this .md file and look at how anchors are made).

mixel
  • 22,724
  • 10
  • 111
  • 154
La Muerte Peluda
  • 1,238
  • 1
  • 8
  • 7
  • 1
    This may do as well. According to this: https://confluence.atlassian.com/bitbucket/mark-up-comments-305037452.html, bitbucket supports the Table of Contents extension which can auto-generate links *and* anchors based on the document headers. The TOC extension is documented here: https://pythonhosted.org/Markdown/extensions/toc.html Add the text "[TOC]" to the beginning of the document for it to be generated. – Binary Phile Jun 29 '16 at 19:47
  • 10
    In Github, `## My paragraph title` will produce the following anchor `user-content-my-paragraph-title`, so you can reference it with [Some text](#user-content-my-paragraph-title). However, I haven't found official documentation for this. – toto_tico Jul 11 '16 at 23:02
  • This helped me on Bitbucket as well - works like a charm. – Scott Byers Jul 28 '16 at 21:41
  • 2
    This is useful information; thank you. However, markdown renderers without the extensions won't generate these anchors for you, and clashing heading names will result in clashing anchor ids (or some unhelpful distinguishing trick, like number suffices). Explicit anchor ids are better, more controllable, not subject to random changes due to text updates (see trick above) and useful for anchoring more than just headers. Both techniques are needed in general. – Steve Powell Sep 18 '16 at 14:55
  • On [stackedit.io](http://stackedit.io) `[linky](#header)` was a sufficient anchor, and worked when published to Gist, too. – Felipe Alvarez May 18 '17 at 04:15
  • 1
    The accepted answer works for bitbucket now and this doesn't. – heez Nov 19 '18 at 21:35
  • You can track changes here: https://jira.atlassian.com/browse/BSERV-4532 – Alexey Vazhnov May 28 '21 at 17:22
68

Use a name. Using an id isn't necessary in HTML 5 and will create global variables in your JavaScript

See the HTML 5 specification, 5.9.8 Navigating to a fragment identifier - both id and name are used.

It's important to know that most browsers still turn IDs into global variables. Here's a quick test. Using a name avoids creating globals and any conflicts that may result.

Example using a name:

Take me to [pookie](#pookie)

And the destination anchor:

### <a name="pookie"></a>Some heading
Wolf
  • 8,482
  • 7
  • 48
  • 92
mikemaccana
  • 81,787
  • 73
  • 317
  • 396
  • 5
    Downvoting. The global variable argument is weak since you shouldn't be (directly) defining global variables in your JS anyway, so no conflict will happen. Also, the semantics of `name` and `id` are different. – Marnen Laibow-Koser Sep 11 '14 at 18:22
  • 11
    @MarnenLaibow-Koser Nobody is discussing defining global variables in JS. **Making an ID in HTML creates a global window.someid in most browsers.** – mikemaccana Sep 12 '14 at 09:42
  • 1
    I know. But unless *your own* JS defines global variables, the `window.someID` variables won't hurt anything. – Marnen Laibow-Koser Sep 13 '14 at 00:53
  • 16
    @MarnenLaibow-Koser Many libraries (i.e., not your own JS, but someone else's) use a single global - for example, fineuploader. If you make an element with an ID of `fineuploader`, you will be unable to use the `fineuploader` module. Avoiding creating unnecessary globals helps avoid those conflicts. – mikemaccana Sep 14 '14 at 13:34
  • 5
    I would be interested to run some tests of that case and find out which one takes precedence. I appreciate the theoretical issue, but in years of client-side development, I've never had an ID break any client-side JS (provided the HTML was otherwise valid). I'll continue to use them when they're semantically appropriate until I run into actual problems. – Marnen Laibow-Koser Mar 02 '15 at 02:16
  • 2
    @MarnenLaibow-Koser I (and many others) have had HTML IDs break real JavaScript - there's one very practical example in the comment you're replying to! There's many styleguides and companies that always use classes, even for singletons, and this is why. – mikemaccana Jan 04 '16 at 13:48
  • I'm utterly amazed. Then again, I never use global variables in JavaScript. Also, a JavaScript library that creates a global variable with a name that's also legal for an ID (i.e. not `$` or `_`) should be considered *broken*: it's very poor form for a library to pollute the global namespace that much. – Marnen Laibow-Koser Jan 05 '16 at 20:00
  • @MarnenLaibow-Koser TBH globals are dead for folk that use browserify or similar, but for libraries that use globals (eg, people that use ` – mikemaccana Jan 06 '16 at 17:39
  • No one should be doing libraries that way now that decent module systems and build tools exist for JavaScript. – Marnen Laibow-Koser Jan 07 '16 at 20:55
  • @MarnenLaibow-Koser Yep. 100% agreed everyone should be using module systems now. However there's still quite a few companies that, even in 2016, publish JS libs with "Just drop this ` – mikemaccana Jan 08 '16 at 02:03
  • Programming defensively is only useful where you don't have full control of the environment. That is not the case here, as I understand it. In other words, the onus for programming defensively is on the library authors, not the ultimate user of those libraries. Also, 'drop this ` – Marnen Laibow-Koser Jan 09 '16 at 21:06
  • 2
    "'drop this – mikemaccana Jan 20 '16 at 13:32
  • Although I still maintain that those libraries are poorly written for doing that, the fact is that you're not going to use more than about 3 on any page, so there won't be more than about 3 reserved IDs to worry about. If you can't get a better modularized library, just avoid the reserved IDs -- don't throw the baby out with the bath water by claiming that IDs are dangerous. (Also: "popular" libraries? I can't find any info on twttr, and had never heard of Olark before. `window.Stripe` normally won't be an issue: who the heck uses capital letters for element IDs?) – Marnen Laibow-Koser Jan 22 '16 at 21:33
  • 1
    Also, the whole argument is silly for the following reason: if there's a conflict between an ID and something else, _the something else takes precedence_. See https://jsfiddle.net/pcj1pgnk/: `window.Stripe` still refers to the Stripe object, even though there's a `
    ` with ID `Stripe` (at least in Chrome). So as long as you don't rely on the divs-as-globals behavior (which no one does), it won't break anything because it will always yield.
    – Marnen Laibow-Koser Jan 22 '16 at 21:41
  • 2
    @MarnenLaibow-Koser Agree. In addition, [the very syntax of a HTML id](https://www.w3.org/TR/html4/types.html#type-id) allows id values containing hyphen, colon and dot, the use of which will make impossible the translation of an ID into a variable name, global or not. – Adrian Colomitchi Dec 17 '16 at 21:13
  • @AdrianColomitchi colon and hyphen and dot can all be used as variable names in JavaScript. However that's still beside the point: n global variables (where n is the amount of IDs in use) isn't a good idea. – mikemaccana May 30 '17 at 11:14
  • @mikemaccana They won't hurt anything if your own JS uses proper practice, so you can safely ignore them. – Marnen Laibow-Koser Apr 19 '18 at 21:53
20

Markdown Anchor supports the hashmark, so a link to an anchor in the page would simply be [Pookie](#pookie)

Generating the anchor is not actually supported in Gruber Markdown, but is in other implementations, such as Markdown Extra.

In Markdown Extra, the anchor ID is appended to a header or subhead with {#pookie}.

Github Flavored Markdown in Git repository pages (but not in Gists) automatically generates anchors with several markup tags on all headers (h1, h2, h3, etc.), including:

  • id="user-content-HEADERTEXT"
  • class="anchor"
  • href="#HEADERTEXT"
  • aria-hidden="true" (this is for an svg link icon that displays on mouseover)

Excluding the aria/svg icon, when one writes:

  • # Header Title

Github generates:

  • <h1><a id="user-content-header-title" class="anchor" href="#header-title">Header Title</a></h1>

Therefore, one need do nothing to create the header links, and can always link to them with:

  • Link to the [Header Title](#header-title)
jeffmcneill
  • 1,691
  • 1
  • 25
  • 21
16

There's no readily available syntax to do this in the original Markdown syntax, but Markdown Extra provides a means to at least assign IDs to headers — which you can then link to easily. Note also that you can use regular HTML in both Markdown and Markdown Extra, and that the name attribute has been superseded by the id attribute in more recent versions of HTML.

You
  • 20,363
  • 3
  • 45
  • 63
14

For anyone who is looking for a solution to this problem in GitBook. This is how I made it work (in GitBook). You need to tag your header explicitly, like this:

# My Anchored Heading {#my-anchor}

Then link to this anchor like this

[link to my anchored heading](#my-anchor)

Solution, and additional examples, may be found here: https://seadude.gitbooks.io/learn-gitbook/

keyoxy
  • 3,671
  • 2
  • 19
  • 17
9

Late to the party, but I think this addition might be useful for people working with rmarkdown. In rmarkdown there is built-in support for references to headers in your document.

Any header defined by

# Header

can be referenced by

get me back to that [header](#header)

The following is a minimal standalone .rmd file that shows this behavior. It can be knitted to .pdf and .html.

---
title: "references in rmarkdown"
output:
  html_document: default
  pdf_document: default
---

# Header

Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. Write some more text. 

Go back to that [header](#header).
symbolrush
  • 5,643
  • 27
  • 47
7

For most common markdown generators. You have a simple self generated anchor in each header. For instance with pandoc, the generated anchor will be a kebab case slug of your header.

 echo "# Hello, world\!" | pandoc
 # => <h1 id="hello-world">Hello, world!</h1>

Depending on which markdown parser you use, the anchor can change (take the exemple of symbolrush and La muerte Peluda answers, they are different!). See this babelmark where you can see generated anchors depending on your markdown implementation.

Ulysse BN
  • 6,678
  • 2
  • 37
  • 63
  • @imz -- Ivan Zakharyaschev, I've rolled back your edit. It was a really different writing and hard for me to understand the point. The goal of this answer is mostly to link to babelmark and hint that there are plenty solution and answer should not focus on a specific implementation... Maybe commeting your point is a good idea though :) – Ulysse BN Nov 10 '20 at 16:39
  • 1
    Yes, that's OK. Maybe I'll write it down separately. – imz -- Ivan Zakharyaschev Nov 10 '20 at 20:43
5

Using the latest Markdown, you should be able to use the following syntax:

[](){:name='anchorName'}

This should create the following HTML:

<a name="anchorName"></a>

If you wanted the anchor to have text, simply add the anchor text within the square brackets:

[Some Text](){:name='anchorName'}

RmbRT
  • 362
  • 1
  • 9
  • 2
    It seems like only `Maruku` knows about this syntax. [See the babelmark.](https://johnmacfarlane.net/babelmark2/?text=%5B%5D()%7B%3Aname%3D%27anchorName%27%7D%0A%0Ahey%7B%3Aname%3D%27heyAnchor%27%7D%0A) – Ulysse BN May 15 '19 at 13:03
1

I will quickly complement for cases where the header contains emojis, in that case it is simpler to just remove the emoji in the link of the reference. For example

# ⭐ Title 2
....
[Take me to title 2](#-title-2)

There are some cases where this does not work for a weird reason, for example here in setup. The solution in that case is to include the whole code for the emoji as well.

Mike W
  • 901
  • 15
  • 23
1

As we see (from the answers), there is no standard way for this; and different markdown processors would differ in their markdown extension that offer this kind of possibilities.

With pandoc, you can get what you asked for like this:

Take me to [pookie](#pookie)

...

[this is pookie]{#pookie}

This gives (with pandoc-2.9.2.1):

<p>Take me to <a href="#pookie">pookie</a></p>
<p>…</p>
<p><span id="pookie">this is pookie</span></p>

One can also make an empty span with an anchor id:

Take me to [pookie](#pookie)

...

this is pookie []{#pookie}

which would produce:

<p>Take me to <a href="#pookie">pookie</a></p>
<p>…</p>
<p>this is pookie <span id="pookie"></span></p>

Apart from this, for pandoc and for most common markdown generators, you have a simple self generated anchor in each header. (See that and other answers here for convenient ways to (auto)generate and refernce such anchors.)