GitHub Projects filter syntax: every qualifier

GitHub Projects filters are typed into the filter bar at the top of a view as field:value pairs. This page lists every qualifier GitHub documents, shows how to combine them, gives ten filters you can paste into a view today, and points out the places where GitHub's own documentation is unclear. Everything here works in GitHub alone, and the last section covers pasting the same filters into another tool.

How do I filter a GitHub Projects view?

Click the filter bar at the top of the view and type a qualifier, such as label:bug. GitHub suggests fields and values as you type. You can also press Command+K (Mac) or Ctrl+K (Windows and Linux) and type "Filter by" to pick a filter from the project command palette. In the board layout, clicking a value on a card, such as an assignee, filters to that value, and clicking it again removes the filter.

A filtered view shows a dot next to its name until you save it. Open the View menu and choose Save changes to keep the filter for everyone who opens that view.

When you add an item to a filtered view, GitHub applies the filtered values to the new item. Adding an item while status:"In progress" is active sets the new item's status to In progress.

Which qualifiers does GitHub Projects support?

GitHub documents these qualifiers for Projects. Replace the capitalised part with your own value, and quote any value that contains a space.

Text fields have their own rules. title:"Bug fix" matches titles that are exactly "Bug fix", and note:complete matches a Note field that is exactly "complete". A bare word such as API searches the title and every text field. A * inside a field value acts as a wildcard: label:*bug* matches labels containing "bug", title:API* matches titles starting with "API", and label:*support matches labels ending in "support".

The bare-word search matches the start of a word only. GitHub's example is the title "Document full-text search": Doc, full and search match it, while cument, ext and arch do not.

How do AND, OR and NOT work in a filter?

Spaces mean AND, commas mean OR within one field, and a leading hyphen means NOT.

• label:bug status:"In progress" shows items that have the bug label and are In progress.
• label:bug,support shows items with either label.
• assignee:octocat assignee:stevecat shows items assigned to both people. Repeating a qualifier is how you ask for all of several values.
• label:bug,onboarding assignee:octocat assignee:stevecat mixes the two: either label, and both assignees.
• -assignee:octocat, -status:done and -priority:1,2 hide the matching items.
• -no:assignee and -no:priority invert no:, so they show only items that have a value.

GitHub's documentation states that "Projects does not currently support logical OR filters across multiple fields." You cannot write "no milestone or no priority" as one documented filter.

How do I filter by number, date and iteration ranges?

Use >, >=, < and <= for comparisons and .. for an inclusive range. Dates are written YYYY-MM-DD.

• priority:>1 shows priorities above 1, and points:<=10 shows 10 points or fewer.
• date:>=2022-06-01 shows items dated on or after 1 June 2022.
• priority:1..3 shows priorities 1, 2 and 3.
• date:2022-01-01..2022-12-31 shows items dated in 2022.
• points:*..10 uses * as an open end: anything up to and including 10.
• iteration:<"Iteration 5" shows items in iterations before Iteration 5.
• iteration:"Iteration 1..Iteration 4" shows Iterations 1 to 4. The whole range sits inside one pair of quotes.

What do @me, @today and @current mean?

They are keywords that GitHub resolves when the filter runs, so a saved view keeps meaning "mine" or "this sprint" next week.

• assignee:@me shows items assigned to whoever is signed in, and -reviewers:@me shows items you have not reviewed.
• date:@today shows items dated today. date:@today..@today+7 covers today and the next seven days, and date:>=@today covers today onwards.
• iteration:@current, iteration:@previous and iteration:@next select iterations relative to the one running today.
• iteration:@current..@current+3 covers the current iteration and the next three, and iteration:<@current covers every earlier iteration.

The iterations guide covers setting up the iteration field these keywords read.

Which filters work for common views?

These ten cover common views, and each uses only documented syntax. Rename status, date and iteration to the names of your own fields.

Where is GitHub's documentation ambiguous?

Four spots in the filtering docs are unclear, and it is better to test them on your own project than to trust either reading.

1. The updated comparison direction. The docs describe updated:>@today-1w as items "last updated seven or more days ago". Read as a date comparison, > a week ago means updated within the last week, which is the opposite. The docs do not say which reading GitHub applies.
2. last-updated versus updated. The docs' introduction uses last-updated:5days for "hasn't been updated in the last five days", but the qualifier table lists updated:NUMBERdays and then gives only @today examples. Neither table row shows the 5days form.
3. OR across fields. The docs say it is not supported. A capture of GitHub's filter suggestions taken on 5 August 2026 listed AND, OR and Exclude as suggested operators. If your project shows them, GitHub may be rolling this out ahead of its documentation.
4. Which fields the filter bar suggests. In that same capture, a number field and two date fields were missing from the suggestion list even though the docs say they can be compared. Typing the qualifier by hand is the safe route.

How does Gitsu handle the same filters?

Gitsu reads GitHub's qualifiers in its own query box, and adds OR across fields. Press / in a project to open Search this view, type a filter and press Enter. Gitsu stores the filter in the view's ?q= link, so in the web app the same link reopens the filtered view. Gitsu can also build the same filter from chips with + Filter, and both routes produce one filter tree that a single evaluator runs. Save current view keeps the filter, grouping, sort and view mode on your device.

What carries over unchanged, per Gitsu's parser code:

• field:value, commas for OR, a leading hyphen for NOT, and has: and no:.
• assignee:, label:, repo:, reviewers:, milestone:, parent-issue: and reason: resolve to the matching columns.
• is:open, is:closed, is:merged, is:issue, is:pr and is:draft.
• >, >=, <, <= and .. on number and date fields, @me, @today with an offset, and @current, @previous and @next.

Gitsu goes past GitHub in one respect: AND, OR and parentheses combine any fields, so no:milestone OR no:priority is a single filter. GitHub's docs say it cannot express that.

Where Gitsu differs today:

• A bare word matches anywhere in the title or body, so cument finds "Document". GitHub matches the start of a word only.
• @today offsets need a unit: write @today+7d, not @today+7. The form without a unit matches nothing.
• * wildcards inside a value (label:*bug*, title:API*) and * as an open range end (points:*..10) are not supported.
• Iteration ranges by name (iteration:<"Iteration 5") and ranges over the keywords (iteration:@current..@current+3, iteration:<@current) are not supported. iteration:@current on its own works.
• last-updated:5days is accepted but matches nothing. Use updated:<@today-5d for the same question.
• type: filters Gitsu's item kind (issue, pull request or draft), not GitHub's organization issue types.

The getting-started guide covers connecting a project, and the Linear vs GitHub Issues comparison sets GitHub Projects against Linear.