How to Convert Plain English to SQL

Developer Tools · 6 min read · Updated 2026-06-18

Describe what you want in plain English and get a SQL query back. Here’s how text-to-SQL works, where it shines, where it doesn’t, and how to use it safely.

SQL is not hard to read, but writing it from a blank editor — recalling exact join syntax, the right aggregate, the grouping rules — slows people down, especially anyone who only touches SQL occasionally. Text-to-SQL flips the workflow: you describe the result you want in plain English, and the tool drafts the query.

Used well, it is a genuine time-saver. Used carelessly, it produces queries that look right and return the wrong numbers. Here is how to get the upside without the risk.

What text-to-SQL actually does

A text-to-SQL tool translates a natural-language request — “total sales per region for last quarter, highest first” — into a SQL query that expresses it: the right SELECT, SUM, GROUP BY, and ORDER BY. It is a drafting aid. It writes the query; it does not connect to your database or run anything, so nothing can be accidentally changed or deleted.

PDFGee’s text-to-SQL tool generates the query right in your browser, so the description you type stays on your device.

Who benefits most

• Analysts and PMs who know what they want but not the exact syntax.
• Developers who want a fast first draft of a tedious aggregation or join.
• Students learning SQL, who can compare their attempt against a generated version.
• Anyone returning to SQL after a break and needing a syntax refresher.

How to write a prompt that produces good SQL

The quality of the SQL tracks the clarity of your description. A vague request gets a vague guess. Include the specifics:

1. Name your tables and key columns. “From the orders table (columns: id, customer_id, total, created_at)…” beats “from my orders”.
2. State the filter precisely. “where status is 'shipped' and created in 2025” removes guesswork.
3. Spell out the aggregation. “count of orders per customer” vs. “total order value per customer” are different queries — say which.
4. Say how to sort and limit. “top 10, highest revenue first.”
5. Mention the dialect if it matters (PostgreSQL, MySQL, SQL Server) — date functions and LIMIT vs. TOP differ.

Turn plain English into SQL → Free and browser-based — your prompt never leaves your device.

Always verify before you run

Treat generated SQL like code from any assistant: a strong first draft to review, not a finished answer to trust blindly. Before running it against real data:

• Check the table and column names match your actual schema.
• Confirm the join conditions are correct — a wrong join silently inflates or shrinks results.
• Sanity-check the aggregation and GROUP BY against what you asked for.
• Run it on a small sample or with a LIMIT first, and never run an unreviewed UPDATE or DELETE.

Where text-to-SQL falls short

It cannot know a schema it has not been told about, so it guesses table and column names unless you provide them. It can struggle with deeply nested logic, window functions, and database-specific extensions. And it has no access to your data, so it cannot reason about what is realistic in your tables. For complex analytics, use it to scaffold the query, then refine by hand.

Already have the data as JSON? You can also generate SQL INSERT statements from JSON, or turn that JSON into C# classes for your application layer.