SQL SELECT Builder

Build SELECT queries visually — columns, WHERE, ORDER BY, and LIMIT.

Table name

SQL Dialect

Format generated SQL (Pretty-print)

Columns (leave empty for *)

idnameemail

WHERE clauses

Join with

ORDER BY column (optional)

LIMIT (optional)

Generated SQL

SELECT "id",
  "name",
  "email"
FROM "users"
WHERE "active" = 1
ORDER BY "created_at" DESC
LIMIT 100;

Visual SQL SELECT builder

This builder lets you construct a SELECT query by filling in form fields rather than writing syntax by hand. String values are automatically quoted; numeric values are kept unquoted. Operators like IS NULL and IS NOT NULL omit the value field. The generated SQL works with PostgreSQL, MySQL, SQLite, and most ANSI-compatible databases.

Related tools: SQL formatter, CSV to SQL converter, and the JSON formatter.

Built and maintained by Meet Shah · Last updated 2 August 2026

What this tool is used for

Composing a SELECT with joins and conditions visually.
Getting the clause order right without remembering it.
Producing a query to review before running it.
Building a query for a schema you are unfamiliar with.
Learning the structure of a SELECT by assembling one.

Frequently Asked Questions

In what order does SQL actually execute?: Not the order you write it. FROM and JOIN first, then WHERE, then GROUP BY, then HAVING, then SELECT, then ORDER BY, then LIMIT. That is why you cannot reference a SELECT alias in a WHERE clause — the alias does not exist yet — but you can in ORDER BY, which runs after.
When do I need HAVING rather than WHERE?: WHERE filters rows before grouping; HAVING filters groups after. `WHERE COUNT(*) > 5` is an error because the count does not exist at that stage. Filter individual rows in WHERE — it is cheaper, since fewer rows reach the grouping — and filter aggregates in HAVING.
Is the generated SQL safe to use with user input?: Not as a template. Anything a user supplies must go through a parameterised query — `WHERE id = ?` with the value bound separately — rather than being concatenated into the string. Use this to get the shape of the query right, then replace the literals with placeholders.
Why is IS NULL not written as = NULL?: Because NULL means unknown, and any comparison with an unknown is itself unknown rather than true. `= NULL` therefore matches nothing at all, silently. SQL provides `IS NULL` and `IS NOT NULL` as separate operators for exactly this reason, which is why they take no value here.
What does LIKE cost on a large table?: A leading wildcard is the expensive case: `LIKE 'abc%'` can use a B-tree index, `LIKE '%abc'` cannot and forces a full scan. If you need suffix or substring search at scale, that is a full-text index or a trigram index, not a LIKE pattern.

Common errors and gotchas

Filtering on an aggregate in WHERE rather than HAVING, which the database rejects.
Omitting a join condition, which produces a cross join and a very large result.
Using LIMIT without ORDER BY, which returns an arbitrary subset rather than the top rows.
Assuming the generated query is efficient, which only an execution plan establishes.
Building a query with string concatenation rather than parameters, which is an injection route.