b2KIT

OpenSearch Description Generator

Generate OpenSearch XML description files for adding custom search to browser search bars.

Tested tool guide Tested browser tools Checked August 16, 2026

What OpenSearch Description Generator does and how it behaves

An OpenSearch description file gives compatible browsers and search clients a machine-readable recipe for sending queries to one particular search service. Given a provider name, description, and search URL template, this generator formats those values as an OpenSearch XML document. Its output is a provider description, not a search page or a site search implementation. The detail most often missed is the literal `{searchTerms}` placeholder: the template must put it where the user's query belongs instead of containing a sample keyword or an empty query parameter.

How the result is produced

1

Search URL template

The central value is the template attribute of an OpenSearch `Url` element. In `https://example.com/search?q={searchTerms}`, a client substitutes the user's encoded query for `{searchTerms}` when invoking the provider. Fixed query parameters can remain in the URL. The generated document describes that request pattern, but cannot determine whether the endpoint, parameter name, or declared response type is correct.

2

Description document XML

OpenSearch metadata belongs under the `OpenSearchDescription` root in the `http://a9.com/-/spec/opensearch/1.1/` namespace. The description contains human-readable provider fields and a `Url` declaration for search results. Because the template is stored in an XML attribute, a literal ampersand separating query parameters must be serialized as `&`; after XML decoding, the URL still contains `&`.

Good uses

  • Creating provider XML for a documentation site whose search endpoint already works, such as `https://docs.example/search?q=...`, so compatible browsers or clients can offer that site as a search option.
  • Replacing a hand-written OpenSearch description after changing a site's public name, explanatory text, result media type, or query URL while retaining the required XML structure and namespace.
  • Preparing a provider description for an internal issue tracker, package index, or product catalog that accepts direct URL queries and should be advertised from an HTML page using `rel="search"`.

Limits and checks

  • A well-formed description does not prove that the search endpoint works. Test the template by replacing `{searchTerms}` with a real encoded query and opening the resulting URL.
  • The placeholder belongs only where the variable query should appear. Do not replace fixed filters, parameter names, punctuation, or the entire URL with `{searchTerms}`.
  • Browser support for discovering, installing, and presenting OpenSearch providers varies. Valid XML does not guarantee that every browser will display an add-to-search control.

Common questions

Should I enter a complete search-results URL?

Start with a working results URL, but replace the sample search phrase with `{searchTerms}`. For example, turn `https://example.com/find?q=blue` into `https://example.com/find?q={searchTerms}`. If the search phrase appears in the path rather than a query parameter, replace that path segment instead. Leave required fixed parameters in place.

Will generating the XML automatically add the provider to browsers?

No. The generated document must be served from a reachable URL and made available to the intended client. A website can advertise it with an HTML `link` element using `rel="search"`, the description URL as `href`, and `application/opensearchdescription+xml` as the type. Whether users can discover or install it still depends on their browser.

References and verification

The behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools