MongoDB Query Builder

Build one MongoDB comparison without memorizing braces

The MongoDB Query Builder creates a db.collection.find(...) shell expression for one field, one comparison operator, and one value. It is a compact teaching and drafting aid for basic filters such as “users older than 21” or “orders whose status is not complete.” Four controls map directly to the output: Collection, Field, Operator, and Value.

The initial state is collection users, field age, operator Greater Than ($gt), and value 21. The MongoDB Shell Query result is therefore:

db.users.find({"age":{"$gt":21}})

Changes render immediately. Copy sends that exact one-line expression to the clipboard and displays Copied briefly. The result is shown as code text, not an editable editor. There is no connection to MongoDB and no execution button.

Control-by-control behavior

Collection is inserted between db. and .find exactly as entered. Field becomes a JSON object key. The operator menu provides four choices: equals ($eq), not equals ($ne), greater than ($gt), and less than ($lt). Value begins as text but receives limited type inference before JSON serialization.

If JavaScript can convert the value to a number, the output contains a JSON number. The exact lowercase text true or false becomes a JSON boolean. Everything else becomes a JSON string. Thus:

42      -> 42
3.14    -> 3.14
true    -> true
TRUE    -> "TRUE"
active  -> "active"

Because Number('') is zero, an empty Value is emitted as 0, not an empty string. Whitespace-only input also converts to zero. This is useful to know when clearing a field during editing: the preview remains syntactically complete but may not mean what you intend.

Field names are serialized with JSON.stringify, so embedded quotes and backslashes are escaped safely in that key. Values classified as strings receive JSON escaping as well. Collection names are different: they are directly concatenated and receive no quoting or validation.

A focused example workflow

Suppose a support issue concerns inactive subscriptions. Enter subscriptions for Collection, status for Field, select Not Equals ($ne), and enter active. The builder emits:

db.subscriptions.find({"status":{"$ne":"active"}})

Copy the expression into a scratch file. Before running it, connect to the intended database, confirm collection naming, and consider whether documents with a missing status field should match. In MongoDB, $ne generally also matches documents where the field does not exist. If absence should be excluded, the final query needs an additional $exists condition, which this UI cannot create.

For a numeric threshold, enter orders, total, $gt, and 99.95. Verify the schema stores total as a number rather than a string or Decimal128. MongoDB comparisons are type-sensitive; a valid query can return surprising records when historical documents use mixed BSON types.

Dot notation and nested fields

MongoDB represents nested paths with dots. Entering profile.age as Field produces:

db.users.find({"profile.age":{"$gt":21}})

That is a useful long-tail case for a visual MongoDB find query builder because no special nested-object UI is necessary. Array and embedded-document semantics still depend on MongoDB. A dotted path may traverse arrays, and a simple comparison is not equivalent to every $elemMatch requirement.

Collection dot notation is less forgiving. db.orders.archive.find(...) is not the standard way to address a collection literally named orders.archive; shell bracket notation may be required. Names containing hyphens, spaces, or reserved-looking segments likewise need db.getCollection('name') or bracket access. The generator always uses db.<input>.find, so edit output for non-property-safe collection names.

What the builder intentionally leaves out

This is a single-condition MongoDB query generator. It has no controls for $gte, $lte, $in, $nin, $exists, $regex, $type, geospatial operators, array operators, logical $and/$or, or multiple fields. It also cannot add projection, sort, limit, skip, collation, hint, comment, or explain options. Update, insert, delete, aggregation, and Atlas Search operations are outside scope.

Values cannot be entered as structured BSON. Typing [1,2] creates the string "[1,2]", not an array. Typing {...} creates a string, not an object. null becomes the string "null". ISO date text stays a string rather than ISODate(...); an ObjectId stays a string rather than ObjectId(...); Decimal128 and regular expressions are not constructed.

These omissions keep the preview predictable. Use it to establish basic shell syntax, then move to a code editor or MongoDB Compass for compound conditions and typed BSON.

Shell syntax versus application code

The output targets the familiar MongoDB shell style beginning with db. Application drivers use native objects and asynchronous APIs instead. A Node.js service might translate the filter to:

const filter = { age: { $gt: 21 } };
const users = await db.collection('users').find(filter).toArray();

Do not paste the shell string into an application and evaluate it. Build an object through the driver, validate user-supplied field and operator choices against allowlists, and rely on the driver for BSON encoding. Although MongoDB does not use SQL injection syntax, operator injection and unsafe dynamic field selection remain real concerns.

In modern mongosh, the generated JSON-like filter is appropriate for basic values. Legacy shells and hosted consoles may differ around available helpers, authentication, and result iteration. The tool does not append .toArray(), .pretty(), or cursor controls.

Verification before running a filter

First confirm the database and collection. Then inspect one representative document to verify field path and BSON type. Copy the generated expression, adapt special values with constructors such as ObjectId or ISODate where needed, and add projection to avoid retrieving sensitive or very large fields. Consider a small .limit() while exploring.

Use explain() or Compass plan analysis for important queries. A builder cannot determine whether an index supports the field and operator. Inequality queries can scan many documents, and $ne is often weakly selective. Test with production-like distributions in a safe environment rather than assuming a short filter is inexpensive.

For application implementation, encode the filter as a driver object, add tests for missing fields and mixed types, and enforce authorization outside the query. Read correctness includes tenant boundaries, soft-delete predicates, and field-level privacy, none of which the form knows.

Failure modes and surprising output

An empty Collection generates db..find(...), which is not useful shell syntax. An empty Field is legal JSON as "", but probably does not match the intended schema. Empty Value becomes numeric zero. Numeric conversion also accepts forms developers may not expect, including surrounding whitespace and scientific notation.

The output may be syntactically valid but semantically wrong when the stored field is a string, date, ObjectId, Decimal128, array, or object. A $gt comparison does not perform human-style conversion. Case-sensitive string equality may differ from UI expectations, and collation is not configurable.

The tool does not catch collection injection. Input such as punctuation or method-like text is concatenated directly into the shell expression. Use only trusted collection names and edit to db.getCollection(...) where appropriate.

Keeping examples reproducible

When sharing a generated filter in a bug report, include a minimal representative document and the expected match, not production records. State whether the field is optional and identify its BSON type. If results depend on collation, arrays, or missing fields, document that explicitly. A compact shell expression is easiest to diagnose when another developer can insert one anonymized document, run the filter, and observe the same behavior without access to your database.

Read the preview as JSON inside shell syntax

The field and value are passed through JSON.stringify as part of the filter object, which is why quotation marks and backslashes in those positions are escaped. The operator comes from a fixed four-item selector, so it cannot be replaced with arbitrary operator text through the form. Collection input follows a different path and is concatenated directly after db.. This asymmetry explains why an unusual field can still produce a well-quoted key while an unusual collection can break the surrounding shell expression. For generated examples, keep collection names property-safe or rewrite the copied result with db.getCollection() before running it.

FAQ

Can I add more than one condition?

No. The current UI generates exactly one field/operator/value object.

Why did an empty value become zero?

The builder attempts numeric conversion first, and JavaScript converts an empty string to 0.

Can Value create an ObjectId or date?

No. Those inputs remain strings. Edit the copied shell query to use ObjectId(...), ISODate(...), or the correct driver type.

Does $eq need to be explicit?

MongoDB allows shorthand equality, but this builder always emits the selected operator object, including $eq.

Does the query run in my database?

No. It generates and copies text only. Connection and execution happen in your own shell or application.

Are unusual collection names supported?

Not reliably. The output always uses property-style db.name. Use db.getCollection('name') for names that are not safe property paths.