Handle (edit) other plain text file formats ( rmarkdown, tex, txt, code, etc )

From Obsidian Release v0.10.10 we can open files of any type using quick switcher.
Please, show text based files (.txt, .html, .ahk, .py, .m and other code, …) also in global search (perhaps as option). I Assume, it would be possible to filter them out by something like “path:.md”.
Should this be separate request?

1 Like

I believe it is a mistake to restrict Obsidian files to those with the .md extension.

Markdown as a file format is defined as a subset of plain text. Plain text is an old idea, which predates any restrictions on file extension formats. Plain text files can have any extension, or none. .txt is popular. Markdown files are plain text files. It is fully correct to store Markdown files as .txt.

As Markdown is a subset of plain text, you cannot make assumptions about the file extension of Markdown files. .md, .txt, .markdown are all popular. README files (without an extension) are often in Markdown. Many times Markdown is used as the format for a plain text file stored in a database, not as a file with a specific extension.

I believe the best user experience for Obsidian is as has been suggested here, to provide a choice of file-extensions that the user wants Obsidian to recognise as Markdown.

E.g., brian23498324’s suggestion:

Treat the following extensions as .md files:
.txt, .taskpaper


Because there are other considerations when naming files, outside of Obsidian. I prefer .txt because Markdown is defined as a subset of plain text. .md is an unnecessary extension.


I prefer .txt because Markdown is defined as a subset of plain text. .md is an unnecessary extension. I think for ultra-long-term concerns, .txt is a better choice.

I don’t think Obsidian’s mission statement of “can be used on an existing folder of notes” should require me to change them in this way.


Agreed. Native editor support for .txt, and other file extensions in addition to .md would open a lot of doors for a lot of users.


It is not an unnecessary extension, and .txt and .md should not be treated the same. Markdown files should have the opinionated ruleset of markdown, including its syntax and validation within the editor, which can be enforced by detection of the .md extension. Text files on the other hand require none of that, and should be rendered purely as plain text without syntax highlighting or validation as Markdown has. While MD is plain text from a technical standpoint, it is not treated as such from an editor or UX standpoint.


A community plugin has been released that allows you to edit plain text files.


Completely agree. I want to know whether a file is .md or .txt . It’s very helpful for knowing which programs to use to work with them.
I changed my mind; reasons given below.

This is wonderfully useful; useful enough to be core.
It allows Obsidian commands to work with and in txt files. I don’t want markdown files masquerading as txt files, so I won’t be adding native markdown formatting (I’d convert if I wanted to do that), but applying Obsidian functionality to them gives Obsidian a much wider range of use.

1 Like

Had a chance to think it through further. One big advantage of .txt is that those files can be loaded by word processors, and other programs, that have a far fuller range of tools and features than any markdown editor. No use to people who want to live in Obsidian, but potentially very valuable to people like me who use a range of programs to work with the files.

  • Most of my files are pure text with no formatting. So switching them all to .txt has no downsides but plenty of upsides.
  • Most of the others have markdown formatting simply to facilitate Obsidian’s functions. Since deathau’s plugin preserves those, there’s no downside to switching those too.
  • Most of what remains have a small amount of markdown to format text. That formatting works perfectly well in Obsidian with the plugin, but not in other markdown editors. So this leaves me with a functional question of whether I gain more from switching to gain access to a wider range of tools, or whether it is best to stay aware that these are markdown files. For the moment at least, I will keep them as they are.
  • The others either have much more text formatting or aree hardcore markdown (such as those with tables), so they will stay as they are.

What has surprised me is how few of my of my files will be kept as markdown.
Of course, new files are automatically markdown, unless they are created in another program and then saved into the Obsidian vault. That’s probably the way I’ll go because it will save me time.

It strikes me that an interesting and useful, for some people, option for the WYSIWYG/WYSIWYM editor would be if the 3 views (source, preview, WYSIWYG) could have a 4th (txt) added.


You are correct that there can be uses for the .md extension. I should have said, for my use case I find it unnecessary.

I want my notes to be a set of plain text files, with the extension .txt.

I believe .txt is the best extension choice for my notes. .txt is likely to outlast Markdown. .txt better expresses what my notes are: at core, they are a collection of plain-text files.

As Markdown syntax is perfectly readable in plain text editors (this is the point of Markdown), I don’t lose anything by using Markdown syntax in my notes, and gain much. This is an excellent property of Markdown – it can be treated as plain text!

When opening my notes in editors that have extra features for Markdown, I tell those editors to assume Markdown syntax for all notes in my archive. As Markdown is backwards-compatible with plain text, this doesn’t break when some of my notes aren’t using any Markdown syntax.

I would like to be able to tell Obsidian, “treat these .txt files the same as any other Obsidian note”.

The community plugin was very interesting, thank you. But I think it doesn’t allow me to link to .txt files without the extension, and view them in the Graph view. Using this extension feels like .txt files are second-class to the .md notes.


Yes, only .md are citizens; the plugin allows .txt to be more than tourists but not really close to a green card. But useful as far as it goes.

I’ve been trying to test out its limits.

  • As you say, they don’t show up in the graph.
  • Linking works, but not as smoothly and possibly only partially: .txt to .txt links seem to work when typed out in full, but the popup will claim no file of that name exists when it’s being typed out (I assume this is an underlying Obsidian filter).
  • Transclusions work when the transcluded file is md, pdf etc but not txt (same as normal Obsidian behaviour).
  • If you type in an existing tag, the popup appears, but the tag doesn’t register on the tag pane.

I had been expecting to convert many of my md files to txt, but I’m not so sure if they can’t then be transcluded - I’d just assumed that if they were capable of transcluding they would themselves be able to be transcluded; I’d want tag functions working too. There are presumably more limits that I haven’t encountered yet. The plugin does what it says it will do, but Obsidian seems to limit how far it can go.

I understand this and it would suit me too. Defining which plaintext file extensions should be treated the same as .md would help many users’ workflow going by the posts above.

This would be an issue if there were two identical names in the vault, but surely checking for this would be little more difficult than checking for .md clashes. The OS will prevent identical names in a folder, but I assume that checks on clashes when naming new files are done within Obsidian itself, and identical md names in different folders simply show the filepath. And some users have no .md extensions but .txt only. And setting up links works with deathau’s plugin, so long as the filename is typed out in full.


afaics the plugin activates everything that a md file can do from the page.

But nothing that requires Obsidian to target and recognise the file as an md equivalent works. I assume that requires changes deeper in Obsidian than the plugin can reach.

I don’t see any reason why it wouldn’t be possible for Obsidian to display a txt page in the same way it does pdf. That should enable transclusions.

Links, tags, backwards links, graph etc would depend on Licat deciding that any obstructions could be circumvented. He’s more than busy enough with higher priority issues (mobile) now, so I wouldn’t want to distract him with this, but it might be worth raising again when the switch to codemirror 6 and WYSIWYG moves to the fore.

It would certainly open a lot of doors if it could be done.

As @saullhow commented, .txt simply indicates a plaintext file. It excludes no form of plaintext markup or any other coding. Virtually all editors will happily open and edit .txt files.
So the value of defining it as excluding markup will depend on a user needing to know that an unopened file contains no markup. I doubt this includes many users, though it could be important to some writers.
.md isn’t a particularly well defined extension in that it doesn’t define the exact markup language used (unlike, for example, .mmd). This means that there is always an open question of the level of compatibility between the markdown in a .md file any any particular markdown editor. Most editors don’t support wikilinks still and no others support the small number of Obsidian specific instructions.
For users who only use Obsidian or Github flavour editors and need to keep to easily identify pure text files, I can see the value of separated .md and .txt extensions, but I doubt that’s a high proportion of users.
If Obsidian recognised .txt as well as .md all the value of the distinction would be preserved in any case.

Despite the existence of specific extensions (.asciidoc & .adoc), asciidoc recommends users use .txt.

Allowing users to specify .txt (and preferably any plaintext extension) as interpretable files within a vault, Obsidian would greatly increase its interoperability with other programs.
Given the choice, I’d choose .txt as the default over .md.


All notes I have are in .txt format. I use multiple platforms, online and synced with dropbox. The main reason for using .txt rather than .md or other formats is that it is natively searchable and can be edited natively by all platforms. There is no reason to require .md as an extension since obsidian could simply interpret the .txt as markdown if the user wanted this. TodoPaper has been doing this for years and works fine showing inline MD. Please for the love of simplicity make this an option users can select. With how amazing everything else is, you think this would have been one of the first things to incorporate lol

1 Like

so … a note taking app that can’t use .txt natively, yet has an option to automatically import HTML into markdown … first line could just be #!/bin/md lol

The plugin mentioned above provides the functionality you’re looking for:

I’m moving this thread to archived. @Dor, feel free to start a new thread for the specific .txt features you’re looking for.

The heading includes a wide range of plaintext files, not just .txt.

Yeah, I think it’s best to create a precise feature requests for each, with specific discussion about what a user would need from that format. Since Obsidian can now be extended to use other formats, perhaps plugins will be developed to respond to these needs.

The majority of discussion on this thread is about .txt, and I am certain that the plugin I mention satisfies that need.

(As I suggested above, I think you’re looking for something different for .txt than the majority of users interested in .txt compatibility.)

It doesn’t allow Obsidian to treat .txt the same as .md. So no tags, links or graphs and they’re not transcluded. While that seems to be enough for some of the posters above it’s certainly not all.

It’s not a big issue for me, which is probably why I came into it so late, so I’ll not submit a new FR. I don’t use Obsidian for tags or search, because it’s too restrictive, and I’ve never found graphs useful. So I only need to make sure I have .md copies of notes where linking will be important.

1 Like

I suggest to move single file support requests to plugins and create a FR to define a “user-customizable extention for the notes files”.

It can be either .md or something else, but it can’t be a mix of extentions because in obsidian the filename has to be unique and we would have problems handling where [[note title]] points if there is note title.md and note title.txt and both are valid targets.

IMHO, This is gonna be a low priority FR because the supporting arguments for .txt are weak.
Both window search and apple spotlight index .md files just fine.

1 Like