Laravel query() vs input(): The Real Difference, With Examples

Last updated: October 14, 2026

Two methods, one request, and a lot of confusion. In Laravel, `$request->query()` and `$request->input()` both return data from an incoming HTTP request, but they read from different places, and that difference matters when you are writing controllers that handle multiple HTTP verbs.

Method comparison

The Laravel documentation makes this explicit: `input` retrieves values from the entire request payload, including the query string, while `query` retrieves only values from the query string itself. The practical consequence is straightforward: `input()` works with any HTTP verb—GET, POST, PUT, PATCH—while `query()` returns only what appears in the URL.

If data is sent in the URL query string, both methods return it. If data is sent via POST in the request body, only `input()` will see it.

Why it matters

The PHP parallel is the cleanest mental model. `input()` behaves like `$_REQUEST`, pulling from both query string and form data. `query()` behaves like `$_GET`, the query string only. If you have written raw PHP, this clicks instantly. If you have not, remember the verb split and you are covered.

The subtle trap is intent. Reaching for `input()` by default is convenient, but it blurs the contract of a controller action. If a route is meant to be read-only and idempotent—say, a search endpoint—accepting values from `input()` means a POST body can quietly change behaviour. Using `query()` makes the contract explicit: this action only reads from the URL. That habit pays off when someone curls your endpoint at 2am or when a junior developer adds a POST fallback without realising it.

The practical split:

• Search, filters, pagination**: `query()` is correct. These belong in the URL so links are shareable and bookmarkable.
• Form submissions, create/update operations**: `input()` is correct. The data lives in the request body.
• Hybrid endpoints handling both**: Prefer `input()` for safety, or be deliberate about `query()` when the read-only contract genuinely matters.

Worked example

Consider a product search endpoint at `/shop?category=shoes&sort=price`. Your controller reads the filters like this:

“`

$category = $request->query('category'); // 'shoes'

$sort = $request->query('sort'); // 'price'

“`

If someone POSTs to the same URL with a body of `category=hats`, the POST body is ignored. The endpoint stays a true read. That is exactly what you want for a search—users can share the URL, and nothing hidden in a request body will alter results.

Now handle a checkout form posted from a Blade template. The form posts to `/checkout`. The line items live in the body, so write:

“`

$cart = $request->input('cart');

“`

Using `$request->query('cart')` here returns null, producing a confusing bug report that wastes debugging time.

What to watch next

• Controllers that rely on `input()` where `query()` would enforce a cleaner read-only contract.
• Form submissions assumed to be GET but quietly handling POST data through `input()`.
• API endpoints where the verb-to-method mapping affects idempotency and caching behaviour.

Key takeaways

• `input()` reads the full request payload; `query()` reads only the URL query string.
• The native PHP analogy: `input()` maps to `$_REQUEST`, `query()` maps to `$_GET`.
• Use `query()` for filters and shareable URLs, `input()` for form bodies and POST data.