Everything HTTP JSON Query Not Working: How to Fix It

When an Everything HTTP JSON query is not working, the problem usually falls into one of four categories: the request uses an incorrect or unencoded parameter, the HTTP server is not configured as expected, Everything itself is returning incomplete search results, or Windows is changing what the running Everything process can access. The safest way to troubleshoot is to separate these layers instead of changing several settings at once.

This guide focuses specifically on API-style HTTP query strings sent to the HTTP server in voidtools Everything. It does not cover the unrelated Windows Search service. Everything maintains its own filename index and can also index configured folders, while Windows Search uses a different index, service, and query system. A Windows Search repair will not normally fix missing Everything HTTP JSON results.

1. Confirm the Symptom With a Small Safe Test

Begin with a predictable filename and the smallest possible local request. This reveals whether the failure is in the HTTP server, the query string, JSON output, or the underlying Everything index.

1.1 Create a Known Search Target

Create a harmless file with a distinctive name, such as everything-http-test-4821.txt, in a location that Everything is expected to index. First search for that exact name in the normal Everything desktop window.

If the file appears in the desktop interface, the index can see it and you can proceed to HTTP testing. If it does not appear, stop changing HTTP parameters. The problem is currently an indexing, exclusion, path, or account-context issue.

1.2 Test a Minimal Local HTTP Request

With the Everything HTTP server enabled, use a browser or HTTP client on the same computer and request a minimal query similar to:

http://127.0.0.1:YOUR_PORT/?search=everything-http-test-4821.txt&json=1

Replace YOUR_PORT with the configured HTTP server port. Using 127.0.0.1 avoids DNS, router, and remote firewall variables during the first test.

Success means the server responds and the JSON contains the known file, or at least reports a matching result count consistent with the desktop search. Once that happens, stop changing server and index settings. Move on to comparing the successful request with the failing request.

1.3 Understand s, q, and search

Examples and integrations may use short or long parameter names such as s, q, or search to pass search text. Do not assume that every alias shown in an old script, third-party wrapper, or example supports the same behavior in your installed Everything build.

Start with the documented long-form parameter used by the official HTTP server documentation, typically search. After the long form works, test the shorter alias required by your integration. If search=test succeeds while q=test fails, the index is not the problem. Keep the working parameter or update the client that generates the URL.

1.4 Verify the json Parameter

Add json=1 explicitly when JSON output is required. Without it, the server may return its normal HTML results page. A response with HTTP status 200 is therefore not enough to prove that the API-style request worked.

Check the response body and its content type. Success means you receive parseable JSON rather than HTML, a login page, an error page, or a proxy-generated response. If the response begins with HTML markup, verify the URL, parameter spelling, authentication, port, and whether a reverse proxy is replacing the original response.

2. Validate Every Query Parameter Deliberately

Once a minimal query succeeds, add options one at a time. This is faster than inspecting a long URL containing interacting search flags, pagination controls, columns, and encoded characters.

2.1 Encode Search Text Correctly

Search text must be URL encoded when it contains spaces, ampersands, plus signs, percent signs, number signs, question marks, quotation marks, non-ASCII characters, or other reserved characters. Otherwise, the server can interpret part of the filename as another parameter.

For example, a search for budget & forecast.xlsx must not place a raw ampersand in the query value. Use an HTTP library's query-string encoder rather than manually replacing only spaces. Be especially careful with plus signs: many URL parsers treat a plus sign as a space in query data.

Success means the encoded HTTP query returns the same files as pasting the intended text into Everything's search box. If those result sets match, stop modifying encoding and inspect any additional flags.

2.2 Check Case, Whole Word, Path, and Regex Flags

The case, wholeword, path, and regex options can legitimately turn a broad search into zero results:

• case: Requires the capitalization rules selected by the option.
• wholeword: Prevents partial word matches that would otherwise appear.
• path: Includes full path information in matching rather than considering only the filename.
• regex: Interprets the search as a regular expression instead of ordinary Everything syntax.

Remove all four flags and retry the known filename. Then add each required flag individually. Regex deserves special attention because backslashes and other metacharacters may need handling both as regex syntax and as URL data. A pattern can also be valid while being more restrictive than intended.

Success means the result disappears only when a specific flag is added. At that point, stop changing the index or service. Correct that flag or the associated search expression.

2.3 Test count and offset

The count and offset parameters control pagination. An offset beyond the available result range can produce an empty result list even though matching files exist. A count of zero, an invalid value, or a client-side conversion error can create similarly confusing output.

Temporarily remove both parameters. If results return, add a small positive count and an offset of zero. Also inspect the total-result metadata separately from the returned page. A response can report matches while returning no rows because the requested page begins after the last result.

Success means offset zero returns the first page and increasing the offset produces later pages without unexpected gaps. Once pagination behaves correctly, do not rebuild the index.

2.4 Review Column Parameters

HTTP JSON requests can ask for result columns such as names, paths, sizes, dates, or attributes, depending on the options supported by the installed Everything version. A client may appear broken when the search succeeded but a column it expects was not requested, was renamed in the client, or is absent for that item type.

First request the default JSON response without optional column parameters. Inspect the actual field names and values. Then enable columns one at a time using the parameter names documented for your build. Treat missing metadata differently from missing search results. For example, a result can exist even if a requested size or date field is unavailable.

Success means the base result remains present as columns are added. If a downstream script fails only after a column is enabled, repair its field handling instead of changing Everything's index.

3. Check the Everything Settings Behind the Results

If both the desktop interface and HTTP response omit the same file, troubleshoot Everything's search and index configuration directly.

3.1 Clear Filters and Search Options

Select the broad Everything filter in the desktop application and clear the search box before testing again. A restrictive filter can hide files by extension or other criteria. Also review Match Case, Match Whole Word, Match Path, and regular-expression modes so the desktop comparison uses the same semantics as the HTTP request.

Check result-omission and exclusion settings as well. An excluded path, hidden-result rule, or omitted result can make Everything results appear incomplete even though the server is functioning normally.

3.2 Check NTFS Indexes, Folder Indexes, and File System Type

Everything can rapidly index local NTFS volumes using NTFS metadata. Other locations may require folder indexing or another supported configuration. A network share, NAS path, removable device, or non-NTFS volume should not be assumed to appear automatically.

Open Everything's index options and confirm that the relevant local volume or configured folder is included. For a folder index, verify that its path still exists and that the account running Everything can enumerate it. Review exclusions for both exact paths and patterns.

Success means the known file appears in the desktop results after the relevant index updates. Retest the minimal HTTP JSON request immediately. If it now returns the file, stop changing HTTP options.

3.3 Check the Service and Running Instance

Everything may use the Everything Service to access NTFS indexing information without requiring the desktop application to run elevated. Confirm that the service state and application configuration are consistent. Also make sure the HTTP request is reaching the same Everything instance whose desktop results you inspected.

This matters when portable copies, named instances, multiple user sessions, or different startup shortcuts are present. Two instances can have separate configuration files, indexes, ports, and folder lists. Check the HTTP port in the active instance rather than relying on memory or an old shortcut.

Success means the process listening on the HTTP port uses the expected configuration and returns the same search result as its desktop window.

3.4 Confirm the HTTP Server Options

Review the HTTP server page in Everything Options. Confirm that the server is enabled, the port matches the URL, and any username or password requirements match the client. If command-line options or startup scripts control the server, verify that they are not overriding saved settings.

Portable installations require extra care because the configuration may be stored beside the executable. Starting a different copy from another directory can load different settings. Use the executable and configuration you intend to keep, then repeat the local loopback test.

4. Check Windows, Network, and Account Context

Move to Windows and network checks only after proving that the query syntax itself works locally.

4.1 Compare Local and Remote Requests

If 127.0.0.1 works but another computer cannot connect, the JSON query is probably not the root cause. Confirm the destination address, port, network profile, server binding behavior, and Windows Firewall rule for the intended network scope.

Do not expose an Everything HTTP server directly to the public internet merely to test it. File-search results can reveal sensitive filenames and paths. Prefer localhost, a trusted LAN with appropriate controls, or a secured VPN. Limit firewall access to required devices or subnets.

4.2 Understand Mapped Drives and Network Shares

Mapped drive letters belong to a logon session and account context. A drive mapped as Z: in your interactive session may not exist for a service, elevated process, scheduled task, or another user. Use a properly configured UNC path for a folder index when appropriate, and ensure the running account has permission to enumerate the share.

NAS availability also affects folder indexes. Confirm that the share is online and accessible from the same Windows account and context running Everything. Success means that account can list the target directory and Everything's folder index subsequently includes the known test file.

4.3 Review Security Software Without Disabling It Permanently

A firewall or endpoint-security product can block the listening port, executable, configuration directory, or network-share access. Review its logs and create the narrowest appropriate allow rule if a block is confirmed. Do not permanently disable antivirus or firewall protection.

If temporary diagnostic testing is permitted by your organization's policy, keep it brief, local, and reversible. Re-enable protection immediately and replace broad testing exceptions with a restricted rule.

4.4 Check Startup Behavior

A query may work after manually opening Everything but fail after reboot because the expected instance did not start, started under another account, or launched before a network share became available. Inspect Startup Apps, scheduled tasks, services, shortcuts, and command-line arguments.

Success means the same configured instance starts consistently, listens on the intended port, and can access every indexed location after sign-in or boot.

5. Use Everything's Diagnostic Tools Carefully

5.1 Watch the Status Bar and Index State

The status bar can help distinguish an empty search from an incomplete or updating index. Look for result counts and signs that Everything is scanning or updating. Compare a broad desktop search, the known filename, and the HTTP response.

If the desktop count is correct but HTTP pagination is empty, return to count, offset, and request parameters. If both are missing the file, remain focused on indexes, exclusions, and access.

5.2 Use Force Rebuild Only After Safer Checks

A force rebuild can help when the index is demonstrably stale, but it should not be the first action. First confirm the correct instance, included volumes and folders, exclusions, service state, share availability, and account permissions. Rebuilding the wrong configuration will not add an excluded or inaccessible location.

Use the Force Rebuild control in the relevant index options only when the index should contain the location but fails to update. Allow it to finish, search for the known file in the desktop interface, and then repeat the minimal JSON query.

5.3 Inspect Debug Output and the Index Journal

Everything's debugging facilities can expose startup arguments, server activity, indexing decisions, and access failures. The Index Journal can help determine whether a file-system change reached the index. Enable diagnostics only for as long as needed because logs can include filenames, paths, searches, and other sensitive information.

Reproduce one request, record the exact URL with credentials removed, note the time, and inspect the associated messages. Success is a clear explanation, such as an inaccessible folder, an unexpected instance, or a malformed parameter. Once identified, disable unnecessary logging and correct that specific cause.

6. Run a Clean Temporary Test

If the cause remains unclear, create an isolated test rather than resetting your working installation. Use a separate portable Everything copy or a named temporary instance, following the official guidance for instance separation. Choose a different local-only HTTP port so it cannot conflict with the primary instance.

1. Start the clean instance without importing the existing configuration.
2. Configure only the minimum required index location.
3. Enable the HTTP server on a distinct local port.
4. Create a uniquely named test file in the indexed location.
5. Confirm it in the desktop interface.
6. Send a minimal search request with json=1.
7. Add encoding, flags, pagination, and columns one at a time.

If the clean test works, compare its settings with the original profile, especially filters, exclusions, folder indexes, startup arguments, and HTTP options. Do not copy every setting at once. If the clean test also fails, capture the exact sanitized request, response, Everything architecture and version shown by the application, Windows version, and diagnostic output before seeking support.

7. Quick Fix Checklist

• Confirm the target file appears in the normal Everything window.
• Test through 127.0.0.1 before testing from another device.
• Use the documented search parameter before trying aliases such as s or q.
• Add json=1 and verify that the response is JSON, not HTML.
• URL encode the entire search value with a proper query-string encoder.
• Remove case, whole-word, path, and regex flags, then restore them individually.
• Remove count and offset, then retry with offset zero.
• Request default fields before adding optional column parameters.
• Clear restrictive filters and check exclusions or omitted results.
• Confirm the correct volume or folder index includes the target location.
• Verify the HTTP request reaches the intended Everything instance and port.
• Check service, portable configuration, startup arguments, and account context.
• Verify network shares are accessible to the account running Everything.
• Use firewall rules narrowly and never expose the server carelessly.
• Force rebuild only after confirming configuration and access.

8. Frequently Asked Questions

8.1 Why does Everything return HTML instead of JSON?

The most likely cause is a missing or unrecognized json parameter, although authentication pages, reverse proxies, and incorrect ports can also return HTML. Test a local request with json=1 and inspect the response body rather than relying only on the HTTP status code.

8.2 Why does the JSON report results but return an empty list?

Check pagination first. An offset beyond the final result can produce an empty page while the total count remains positive. Remove pagination, then retry with offset zero and a small positive count.

8.3 Why do spaces or ampersands break my search?

They have special meaning in URLs. A raw ampersand starts another query parameter, while spaces and plus signs can be decoded differently by clients. Pass the search value through a standard URL query encoder.

8.4 Why does Everything find a file in the desktop app but not through HTTP?

Compare search flags, filters, request encoding, pagination, and the active instance. The HTTP port may belong to another portable or named instance with a different index. A path, regex, whole-word, or case option can also make the HTTP search narrower.

8.5 Why are NAS or mapped-drive results missing?

Everything may need a configured folder index for the share, and the running account must be able to enumerate it. Mapped drive letters are not always visible to services, elevated applications, scheduled tasks, or other users. Confirm access from the same account context and consider an appropriate UNC path.

8.6 Is this a Windows Search problem?

Usually not. voidtools Everything and Windows Search maintain separate indexes and use different services and query systems. Repairing or restarting Windows Search will not normally correct an Everything HTTP JSON request. Focus on Everything's HTTP options, index configuration, service, instance, and access to the target location.