Install Obsidian
You need the Obsidian desktop or mobile app and a vault where your Markdown notes live.
Learn moreDataview Query Builder Tutorial
This Dataview Query Builder Tutorial teaches you how to create your first useful DQL query without writing every line by hand.
Follow the five steps below to choose a query type, set a source, add filters, copy the generated code, and paste it into an Obsidian note.
Open Dataview Query Builder β
No sign-up required. Free and runs in your browser.
Before You Start
Install and enable the Dataview community plugin
Open Obsidian Settings, enable community plugins, search for Dataview, install it, and turn it on.
Learn morePrepare a few notes with fields or tags
A small test vault is enough. Add frontmatter such as status, due, priority, or tags so the generated query has data to read.
Create your first DQL query in 5 steps
Step 1: Open the tool
Open the Dataview Query Builder and start from the prefilled demo query instead of beginning with a blank screen. This first step matters because a working TABLE query gives you a safe reference point: you can see the selected query type, the Projects folder source, the status filter, the sort rule, and the generated DQL all at the same time. Many beginners make the mistake of changing several controls immediately, then they cannot tell which change broke the output. Read the preview first, compare each visual control with the DQL line it creates, and only then begin editing. A useful tip is to keep the demo query intact for a minute and copy it into a scratch Obsidian note; if it renders after you adapt the folder name, you know your Dataview plugin and code block format are working.
Open the homepage tool and review the generated preview.
Step 2: Choose a query type
Choose the query type before you adjust fields, because TABLE, LIST, TASK, and CALENDAR each answer a different kind of question. TABLE is best when you need a dashboard with columns such as status, due date, owner, rating, or project. LIST is better when the result should stay compact, for example a reading queue, a set of tagged notes, or a recently edited index. TASK should be used when you want Dataview to collect Markdown task items from inside notes rather than return the notes themselves. A common error is using TABLE when you only need links, which creates unnecessary columns, or using LIST when you actually need to compare several fields. The small tip here is to decide what the final result should look like inside Obsidian first, then pick the query type that matches that result.
Select TABLE, LIST, or TASK at the top of the builder.
Step 3: Set the data source with FROM
Set the FROM source so Dataview knows which part of your vault to search. Use a folder such as Projects, Meetings, Reading, or Daily when the notes live together in one place, and use a tag such as #project or #research when related notes are spread across several folders. This step is important because most empty query results come from an incorrect source, not from a broken WHERE rule. Be careful with folder capitalization, nested folder names, and quotation marks around folder paths; a folder called Projects/Active is not the same source as Projects. For tags, make sure the notes actually contain the tag in a place Dataview can read. A practical tip is to test the source alone first with a simple LIST query before adding filters, sorting, or limits.
Choose Folder or Tag, then enter the source value.
Step 4: Add filters with WHERE
Add WHERE filters after the source works, because filters are meant to narrow a valid result set rather than discover notes from scratch. A rule such as status != archived hides completed or inactive project notes, while priority >= 3 surfaces important items, contains(tags, work) finds notes that include a specific tag value, and due < date(today) can help build an overdue review. The most common mistake is filtering on a field that does not exist in every note or using a value type that does not match your frontmatter. For example, a date field should be stored as a real date value if you want reliable date comparisons. Add one filter, check the preview, and test it in Obsidian before adding another. A good tip is to temporarily remove the WHERE line whenever a query returns nothing; if results appear, the source is fine and the filter needs attention.
Add one WHERE rule at a time so empty results are easy to debug.
Step 5: Copy and paste the generated DQL
Copy the generated DQL only after the preview matches the query you intend to test. Paste the full dataview code block into an Obsidian note, not just the DQL lines, because Obsidian needs the fenced code block language to hand the query to the Dataview plugin. If the note shows plain text, check that the opening fence is exactly marked as dataview and that the plugin is enabled. If the note shows a Dataview error, read the error line first; it usually points to a field name, quote, operator, or value type problem. After the query renders, adjust the folder names and field names to match your real vault. A useful tip is to keep a dedicated testing note in Obsidian where you paste new queries before moving them into dashboards or permanent review notes.
Use the sticky Copy button in the preview panel.
Practice with the tool
Use the Dataview Query Builder while reading this guide, then compare your generated output with these Dataview query examples. The fastest way to learn is to change one control at a time and watch the DQL preview update.
If you already know the field names in your vault, open the Dataview Query Builder and build the same query with your own folder, tag, and WHERE conditions.
Frequently Asked Questions
What if the generated query shows no results in Obsidian?
Start by confirming that the Dataview community plugin is installed, enabled, and allowed to run in the current vault. Next, simplify the query to only the query type and FROM line, because this tells you whether Dataview can find any matching notes before filters are applied. If the simplified query works, add each WHERE condition back one at a time and check which condition removes all results. Pay close attention to folder spelling, tag spelling, field names, and value types such as dates, booleans, numbers, and strings. Also open one note that should match and verify that its frontmatter or inline fields use the same names as the query. This step-by-step reduction is faster than guessing, and it prevents you from rewriting a good query when only one field is mismatched.
Which Dataview query types are supported?
The tutorial covers the core workflows for TABLE, LIST, TASK, and CALENDAR-style queries, with the strongest focus on the visual builder patterns that users need most often. Use TABLE when you need columns and comparisons, LIST when you need a simple index of notes, and TASK when the output should collect Markdown task items from matching notes. CALENDAR queries follow the same basic thinking around sources and date fields, although the exact output depends on how your vault stores date metadata. If you are unsure which type to pick, start with LIST to confirm that the source works, then move to TABLE when you need fields or TASK when you need task lines. Keeping the first query simple makes later debugging much easier.
Does my data get sent to a server?
No. The builder generates DQL text in your browser and does not upload your Obsidian vault, note contents, folders, tags, or frontmatter to a server. You manually type folder names, field names, tags, and filter values into the form, and the tool turns those inputs into a query string. That privacy model is useful because many Obsidian vaults contain personal notes, client details, research material, or private planning data. You can still copy the generated code into Obsidian, but the actual query execution happens inside your local Obsidian app through the Dataview plugin. If you work with sensitive vaults, avoid pasting private note contents into any web tool; for this builder, only the query structure is needed.