I write my notes in Spanish (550+ million speakers 
) and I stumble upon this almost daily. Would love to see it addressed soon. Thank you, team! 
+1
- This is would help me tremendously, first in link suggestions, then in the quick switcher and in search.
- It would match the behavior of all the other applications I use (e.g., Microsoft Office, Windows file search, etc.)
Language as option
Allow users to select a language, or even a single sign, to use for searches.
Few signs will not significantly slow down searches.
In my case; I don’t have a problems as in example from @dreamdoggo
Yes, it is part-solution, but solves more than half of cases.
Plugins can’t maintain current “flow”, until you give plugin devs more power.
Thanks for sharing, I didn’t know about it. I tried it a while ago but discarded due to this issue, know I will give it another try.
Personally, till a complete solution gets implemented, making it a toggle explaining the drawbacks would suffice.
2026, still absolutely needed. Thanks.
June 2026, still a very needed core feature.
Just to add my plus one
I hope this issue, which has been discussed here since 2020 and remains one of the most requested features, will soon be addressed by the professional Obsidian team. As some users have rightly pointed out, the issue isn’t limited to diacritics; it extends to any case where formatting or editing modes inject code into the text, which subsequently restricts search capabilities. Resolving this would significantly enhance my workflow and allow me to rely much more heavily on Obsidian for my daily tasks.
The continued unresolved state of this matter has led me to question the long-term viability of this tool for my professional needs. This is no longer a minor grievance; it is a critical concern. It would be regrettable if such a fundamental flaw were to compel me to seek more robust alternatives
Hello,
Having to rely on regex or third-party indexers like Omnisearch just to find words like “élève” when typing “eleve” adds unnecessary friction to everyday note-taking.
Is there any update from the core team on whether diacritic-insensitive matching will be supported natively in the global search (Cmd + Shift + F) anytime soon?
Accent-insensitive (diacritic-agnostic) search is essential for non-English languages (French, Spanish, German, etc.). Thanks
This is addressed in macOS by character folding in the index, and I think the same approach should be adopted here. Spotlight treats diacritic-insensitivity as a peer of case-insensitivity: c is the case modifier, d is the diacritics modifier, and plain full-text search applies d by default. Searching Souffle and Soufflé returns the same results.
The same two queries against my own vault return 48 and 200+ in Obsidian. Both look like answers, which is the part that costs you. Zero results makes you suspicious; forty-eight results makes you stop looking.
For the folding rules, anyascii is a reasonable source. There is a JavaScript port under the ISC license, so it could be vendored directly. I’d steer away from the obvious shortcut of NFD normalization plus stripping combining marks: it looks correct until it meets a character with no canonical decomposition, and Smørrebrød comes back unchanged.
In re feature versus bug: it is a feature request, sure. But as my mentor used to say, if it sucks, fix it. The distinction is meaningless.
Just moved to Obsidian and almost finished migrating all my notes but was shocked to see that this was an issue. I can’t use the app without this feature. Would really appreciate an update from the team?