Obsidian Titles/Headers

Hi, Is there a way for me to be able to write the title at the top of the pane while simultaneously obsidian writes the same thing at the top of my new page?

Do you mean you want the file name to match the title at the top of the note?

The Filename Heading Sync plugin will keep the file name and first heading in sync; change one and it updates the other:

In addition, if you use the Templates core plugin, you can add the variable {{title}} to the first heading, and when you insert the template, it will replace {{title}} with the file name:

If I understand correctly, this is also how Obsidian will work by default starting with v0.16. (See here for an example or the official update) So you might be able to just wait for that update, and adjust your vault to the new format then.

I’ve been using 0.16 for a bit now, and it’s a super nice feature to have built in. No more duplicate headers!

However, when exports the note into pdf, one still needs to add the header 1 manually.
The header 1 shown in the page is visible in Obsidian only.

1 Like

Ah, good to know. I hadn’t considered exports, but it makes sense.

Lifesaver. :heart:

With the 0.16 feature, I am up for an existential discussion about this…


Why shouldn’t the H1 title get actually written to the file?

The way the 0.16 feature appears to work, the filename is used only to display a H1 title by proxy, it is not written to the file. In other words, this is an Obsidian-specific feature.

But Obsidian promises “Notes for your grandchildren”. In the future, when my grandchildren pick up a bunch of Markdown files, or when I view them using an other application, why wouldn’t they or I want to see a H1 title at the top of the page? It’s like reading a news site article that doesn’t have a true headline - valuable context is lost.

Yes, I notice that the Filename Heading Sync plugin actually writes the title to the top of the file. And, yes, I guess people have the choice. I can just see people getting wrapped up without judicious use.


Semantics, accessibility and the risk of multiplication

There’s another thing I wanted to mention relating to this…

With this feature turned on, a H1 will appear at the top of a document, while the user may already have - or may choose to have - another H1 beneath.

This is semantically incorrect, at least in the web world, where each page should have only one H1, the title of the page. More specifically, each major element like <article> should have only one - an <article> would be analogous to a note, ie. the note file encapsulates a single entity. Therefore, the same rule should apply.

As this Markdown guide says: " f you target HTML output, write your documents so that it will have one and only one h1 element as the first thing in it that serves as the title of the document."

Obsidian/Kepano’s screenshot preview of the new default theme shows exactly this challenge, however - two apparent H1s… one real one, present in the file, and one fake H1, the title of the document.

As GitLab’s Markdown style guide says:

"We don’t use h1 headings, as they already are displayed on every page as its title, and we should not apply more than one h1 per page.

… If you then use a second <h1> on the same page, you’re creating some potential confusion…

Always start with h2

Whether or not is is semantically appropriate or not (to a machine) to have two H1s, having two equivalent headers with equal weighting nevertheless has a visual consequence - this may confuse the user; it feels wrong.


Obsidian should be correct

This is of note because Obsidian’s own docs pages, for example, don’t use H1 headers at all. Instead, they style headers using CSS rules but then dive into H2s. Again, this isn’t quite correct. The end result, with a stepping-down in font weight, looks right, but it actually breaks web accessibility guidelines.

It also jumps from the non-H1 straight to H3 on occasion.



Appropriate use of these feature or plugins may matter to some users because appropriate balance of the feature use and in-note headers may render the Markdown semantically incorrect. This has particular consequences in publishing documents, but also has internal, private relevance.

For example - if a user declines to write in a H1 header, because the 0.16 feature makes one display in the window, they should then logically begin in-page sub-headers at H2. But, since the title isn’t getting written to the file, the first header in the page would then begin at H2.

As @GLight’s PDF export shows, it is entirely appropriate in that case to show the title of the document.

Is the product approach that it is up to the users?


Alternative naming conventions

I have been looking at Dendron’s hierarchical naming convention, wherein all nodes of the note’s hierarchy including itself are contained in the filename, leaving the human-readable title to be expressed in the file.

To prosecute that, I presume the best approach is to leave the feature off and just use names and H1s as I please.


The problem is this: H1 is not defined as document’s the title in the markdown spec. It’s the level 1 header and there could be multiple of that.

The fact is that there is no markdown construct that maps to the html tag title.
Until said construct is introduced (and maybe it never will), the best place for the tile is filename, or if that is too restrictive, a YAML attribute.
The YAML solution is also what is suggested by commonmark.


I’m not sure there is compelling evidence this is true.

Non sequitur. Why would using the inline title preclude using H1? I usually restrict myself to a single H1 per document (personal preference) but again I don’t see an argument for why that should be universal. Cirosantilli’s guide is his opinion.

Inconsistencies in Obsidian’s help corpus are just that - inconsistencies - and (IMO) distract.

At best, H1’s relationship to title is an undefined behavior. It’s unfortunate Gruber didn’t have syntax defined for <html><head><title>... and CommonMark has so far not made any official determination in its spec, that long discourse thread notwithstanding.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.