Search Syntax Documentation

Operator Description Example
Searches within the title and body of the note foo searches for all notes with foo in title or body.
foo bar searches for all notes with foo in title or body and bar in title or body.
foo -bar searches for all notes with “foo” that don’t contain "bar"
"foo bar" does a phrase search.
any: By default all the search terms will be connected by and in the backend (notebook is the only exception). Use the any operator if you want the search terms connected by or instead. any:1 tag:t1 tag:t2 will return notes that have tag t1 or t2.
any:0 tag:t1 tag:t2 wll return notes that have both tags t1 and t2. (Default behaviour)
title: Searches within the title of the note. title:hello searches for notes whose title contains “hello”.
title:“hello world” searches for notes whose title contains “hello” and “world”.
title:hello -title:world searches for notes whose title contains “hello” but not “world”
body: Searches within the body of the note. body:foo searches for all notes whose body contains “foo”.
body:“foo bar” searches for all notes whose body contains both “foo” and “bar”.
body:foo -body:bar searches for all notes whose body contains “foo” but not “bar”.
tag: Searches for notes that have the specified tags. Allows boolean search. tag:office searches for all notes having tag office.
tag:office tag:important searches for all notes having both office and important tags.
tag:office -tag:spam searches for notes having tag office which do not have tag spam.
tag:be*ful does a search with wildcards.
Notes with or without tags tag:* notes with tags.
-tag:* notes without tags
notebook: Searches for notes that belong to the specified notebooks. Multiple notebooks can also be specified since they are connected by or always (ignoring the any operator). notebook:goals limits the search scope within notebook goals and all its sub notebooks.
notebook:the*lord does a wildcard search.
Searches for notes created/updated before/after date specified using YYYYMMDD format. We can also search relative to the current day, week, month or year. created:20201218 will return notes created on or after December 18, 2020.
-updated:20201218 will return notes updated before December 18, 2020.
created:20200118 -created:20201215 will return notes created between January 18, 2020 and before December 15, 2020.
created:202001 -created:202003 will return notes created on or after January and before March 2020.
updated:1997 -updated:2020 will return all notes updated between the years 1997 and 2019.
created:day-2 searches for all notes created in the past two days.
updated:year-0 searches all notes updated in the current year.
type: Searches for notes or todos. type:note to return all notes
type:todo to return all todos
iscompleted: Filter on completed or uncompleted todos iscompleted:1 to return all completed todos
iscompleted:0 for uncompleted todos
Filter by location latitude:40 -latitude:50 filters notes with latitude >= 40 and < 50
resource: Filter by attachment MIME type resource:image/jpeg to get all notes with a jpeg attachment.
-resource:application/pdf to get notes without a pdf attachment.
resource:image/* to get notes with any type of images.
sourceurl: Filter by source URL sourceurl: You can also use wildcards

Note: In CliClient you would need to escape the query using -- when using negated filters.
Eg. :search -- "-tag:tag1".


Should created and updated return just the notes created/updated on YYYYMMDD date or should it also return the notes created after that date too?

I may be nitpicking but is there a way to escape the " to search for something like this
title:"the title of this note is \"title\""

Probably more useful for searching within the body rather than the title.

When I write a note, usually I think of something todo. So I use “- [ ]” to put a checkbox. I also add ** or == or ++ to mark it as important or urgent.

- [ ] **==urgent & important==**
- [ ] **important**
- [ ] ==urgent==
- [ ] ++autre++

Then I could really use something like isimportant: as a shortcut for /"- [ ] **=="
Do you think it could be useful for everyone ?

Thanks for making the doc @naviji. Just a few questions and comments:

  • What if the user doesn’t use any of these operators? What’s being searched by default? I think we should document this.


To keep the implementation more flexible and to make it easier to extend it in the future, I think we should use more explicit placeholders. “notebook:” is a bit longer but I think that’s fine.


Same remark here. I think “is” is a bit vague and could actually apply to other things. Maybe just “type:note” and “type:todo”?

Finally it would be good to define what’s the boolean operator between each terms. So I understand well we default to “AND” everywhere except between certain groups of placeholder. For example, between multiple “tag:” terms, it would be an implied OR.

We don’t need to mention all this in the user documentation as we should make it intuitive to begin with, but it would be good to specify it now to make it easier to implement it and to test the feature.

1 Like

For me, it would be more useful to show notes created since that date.

Good luck!

1 Like

How does github search handle this?

Maybe there’s a way to use > and <, e.g.: created:>20200501 or some other form of range indicators

It would be an implied AND between tags. Implied OR between notebook, created and updated.
(AND doesn't make sense here since a note can't belong to multiple notebooks, be created/updated on multiple dates)

Something like this?

Notes created on that date

Notes created after May 1, 2020

Notes created before May 1, 2020

I think it’s also useful to support ranges between two dates.


Yep, whatever you think makes sense. The options are endless. e.g. for ranges you could also allow partial notations, as you’ve already done with your last example:


But that’s all up to you, but ultimately depends on Laurent’s approval.

For me it seems like the default behavior, not using one of the key words you’ve defined, should be some kind of combination of results with matches in the title AND body. Perhaps this could also be extended to include tags.
Also, forgive me if you’ve already addressed this somewhere else, I’m hoping that the default is a fuzzy search unless specified by " or something else. Generally I don’t know exactly what words or sequence of words I’m looking for. Fuzzy search, in my experience, is superior as a default behavior.
Having said that, I’m really happy you’re working on this, so keep it up!

Not sure if fuzzy search should be the default. Regular non-fuzzy search is what users expect, so that if you search for eg. “red”, you don’t also get “bed”, “ted”, etc. and a ton of unrelated results. I think they have this kind of fuzzy search by default on Thunderbird, which I’ve always found annoying as it makes it impossible to find certain results. But I don’t know, maybe there’s a way to create a fuzzy search that avoids these problems.


You have a point, but those kind of results are typically at the bottom of the list, with exact matches being at the top. If you really want “red” only then specify a non-fuzzy search.

Wouldn’t using tags important and urgent be better?

Then you can search for tag:important to get the important notes.
tag:urgent to get the urgent notes.
tag:important or tag:urgent to get notes that are important or urgent
tag:important -tag:urgent to get notes that are important but not urgent.

Quick suggestion: including parent notebook names in the search (in addition to title and body) would also be quite handy. If I have two notebooks, “Personal” and “Work”, I might have e.g. an urgent list in each, and being able to provide the additional context would be really nice.

I assume you mean this?
notebook:personal urgent

You can already do that. You can combine all of these together.
notebook:personal title:urgent tag:office created:week-2 type:note

for my use, in a same note, one thing "-[ ]" can be important and the other urgent. But I say maybe my use is maybe not the "good" one :slight_smile:

body:foo or body:bar

@naviji, I probably wasn’t clear in my posts earlier but we shouldn’t support and/or operators explicitely. What I mean is that there are implied operators between terms. For example an implied “AND” between “foo bar”, and an implied “OR” between “notebook:one notebook:two”, but we shouldn’t explicitly support it.

All these implied operators, we should document them, but outside of the table. Just as a note for advanced usage or for developers.

So you don’t think we should support boolean search for tags?

tag:t1 tag:t2 or tag:t3 -tag:t4

Like @tessus mentioned, I thought this was a much requested feature?

Without resorting to an AST, we could just do union/intersect/difference as required here.
results(t1) intersect results(t2) union results(t3) difference results(t4)

So the terms are always associated left to right.

Yeah! Don’t know how I missed that. Thanks