SharePoint Search Queries Explained: KQL Basics

Keyword Query Language basics

Mikael Svenson

by Mikael Svenson on 10/23/2014

Share this:

Article Details

Date Revised:

Applies to:
Keyword Query Language, KQL, Microsoft SharePoint, Search, spx

For the past year I’ve written quite a lot of search queries and search query rewrites via query rules in SharePoint 2013, both in customer projects and for presentations. Although documentation is available for you gumshoes out there, I thought I’d digest it all into a series of articles: SharePoint Search Queries Explained - The Series

Here's a list of topics I’m planning to cover. If you have any other suggestions, feel free to drop me a note.

  • S15E01: KQL – The Basics
  • S15E02: KQL – On Kryptonite
  • S15E03: Query Variables – Constant Trouble
  • S15E04: Result Sources – Scope it out out!
  • S15E05: Query Rules – The Basics
  • S15E06: Query Rules – Rewrite, don’t paraphrase
  • S15E07: Query Rules – Get things in order
  • S15E08: Query Rules – I am Trigger happy (intent)
  • S15E09: Query Rules – Trigger happy circumstances (context)
  • S15E10: FAST Query Language (FQL) – The Unwanted Step son
  • Bonus: Content Search squares it off against Search Result

SharePoint query languages

SharePoint 2013 includes two query languages that you can use to formulate your search queries: The Keyword Query Language (KQL) and the FAST Query Language (FQL). KQL is the topic the first two articles in this series. It is the language you will use most when writing search queries and is aimed at end-users. FQL has some extended capabilities over KQL, but you will usually solve your queries using KQL. (FQL is also trickier to execute using the UI/CSOM/REST, but more on that in episode 10.)

Keyword Operators

The basis of KQL is a set of operators and special characters you can use to formulate your queries. The KQL version in SharePoint 2013 also has some enhancements brought over from FQL. This first article will focus on the basics of KQL, while the next will expand on some of the new special operators available (NEAR, ONEAR, XRANK), as well as on crafting complex queries.

Keyword operators are what you will use the most as an end user formulating a query in a search box. Most users will only use variants of the top two, perhaps venturing into doing phrase searches. The table below lists and describes the keyword operators, providing usage and examples.

Note: Search terms entered are case-insensitive but the operators must be in uppercase.





termA termB Free text query One or more terms entered after each other with an implicit AND between each term. A search for Swedish meatballs returns only items that have swedish and meatballs somewhere in them but not necessarily together.
AND/+ Boolean AND operator (the + character may also be used) This is the default operator and need not be specified. It sets the query to return only items with termA and TermB in them. Swedish AND meatballs and Swedish +meatballs and Swedish meatballs are essentially the same query.
"termA termB" Double quotation marks Placing double quotation marks around a multiple-term query makes the query a phrase search - only items that match the terms together in an exact phrase are returned. Searching for “Swedish meatballs” returns only items with swedish and meatballs together. The terms must follow each other exactly and in the specified order.
OR     Boolean OR operator This is the disjunct operator and specifies that matching either of the terms on either side of this operator will satisfy the query. That is, items with either termA or TermB are returned. Searching for Swedish OR meatballs returns any item with the term swedish in it and any item with the term meatballs in it.
NOT/- NOT operator (the – character may also be used) This is the negation operator; it sets a trailing term to be an exclusion query. That is, any item that contains this term is excluded from the result set. Searching for Swedish NOT meatballs returns items that match Swedish but no items with the term meatballs in them are returned. Swedish -Meatballs is essentially the same query.
       * Prefix matching wildcard (postfix is not supported) The wildcard operator can be added to the end of partial words to match terms with 0 or more trailing characters. Essentially, all terms starting with the entered characters up to the wildcard are matched. Searching for Swed* Meat* matches Swedish meatballs, Sweden meatballs, Sweden Meatloaf, Swedish Meat, and so on. These terms are not necessarily together. Phrase search is not supported with wildcards in KQL.

WORDS(termA, termB)


ANY(termA termB)

Synonym operator The synonym operator allows you to specify terms that should be considered synonyms of each other in the query. TermA and TermB should be considered to have the same meaning and, therefore, be searched for. This is equivalent to using the OR operator between termA and termB.

This operator cannot be used with property queries.

Searching for WORDS(Swedish, Svensk) returns all items with the term Swedish and all items with the term Svensk.

The difference between WORDS and ANY is that with ANY the terms are ranked as if they were the same term and not by their individual weight. An item with one instance of Swedish and two instances of Svensk would rank the same as an item with three instances of Swedish.

ALL(termA termB) Boolean AND operator Enclosing terms with the ALL operator is the same as writing the terms with a boolean AND between them.

This operator cannot be used with property queries.

Searching for ALL(Swedish meatballs) returns only items with Swedish and meatballs together.
      () Parenthesis Parentheses are used to enclose and isolate a specific part of a complex query. If an opening parenthesis is used, a closing parenthesis must be provided. Meatballs NOT (Danish OR Norwegian) represents a query where all items with the term meatballs returns as long as the terms Danish or Norwegian are not also present.

Parentheses can also be nested. (Danish OR (Norwegian AND Swedish)) NOT (meatballs OR sausage) represent a query where items containing either danish or norwegian together with swedish, but not meatballs or sausage.

Property Queries and Operators

It is important to note that the property restriction cannot include whitespace between the property name, the property operator, and the property value. If a space is encountered, the query is treated as a free-text query. Also note that a property restriction is limited to 2,048 characters.

If you want to use a managed property in a property restriction, the managed property must be marked as Queryable.

Date properties have a resolution of one day, so you cannot limit items between smaller intervals. Any hours you enter into the comparisons will be ignored.



Supported Property types




Text, DateTime, Integer, Decimal, Double, YesNo




Text, DateTime, Integer, Decimal, Double, YesNo

author:mikael author:”mikael Svenson”


Less than



Greater than

DateTime, Integer, Decimal, Double



Less than or equal

DateTime, Integer, Decimal, Double



Grater than or equal

DateTime, Integer, Decimal, Double



Does not equal

Text, DateTime, Integer, Decimal, Double, YesNo




DateTime, Integer, Decimal, Double

size:2000..3000 is equal to  size>=2000 AND size<=3000

If two property restrictions with the same property are added to a query, then an OR is performed between them, and not the implicit AND, which is used by default with all other terms.

Some examples:

Items where the author is either mikael or garth.

author:mikael author:garth

Items where the author is mikael and garth in the same item

author:mikael AND author:garth

Items where the content type is Document and author is mikael

spcontenttype:document author:mikael

Property Queries and date intervals

In addition to specifying the date manually in a property query, you can use some nifty built-in variables.





Represents the time from the beginning of the current day until the end of the current day.



Represents the time from the beginning of the day until the end of the day that precedes the current day.


this week

Represents the time from the beginning of the current week until the end of the current week. The culture in which the query text was formulated is taken into account to determine the first day of the week.

write<”this week”

this month

Represents the time from the beginning of the current month until the end of the current month.

write<”this month”

last month

Represents the entire month that precedes the current month.

write:”last month”

this year

Represents the time from the beginning of the current year until the end of the current year.

write<”this year”

last year

Represents the entire year that precedes the current year.

write>”last year”

Query for managed metadata

The clue to query against managed metadata is to make sure the columns are site columns, so that you get an automatically created managed property for the column which you can query against. You can use either the label or the unique identifier for the term when querying. If you however want to query on a term which has siblings you have to use another notation:
  • To query for all items that are tagged with a term: GP0|#
    • It is also possible to query against the term default label as well
  • To query for all items that are tagged with a child of term: GPP|#
    • (Note that the parent term is NOT included in the results)
  • To query for all items that are tagged with a term from a term set: GTSet|#
    • (Note that the parent term is NOT included in the results)
If you query against owstaxIdTaxKeyword, then hierarchies will not work, only the individual term.

If you have a site column named location tied to a taxonomy, you will have the corresponding managed property yo query against: owstaxIdLocation.

Given the following taxonomy

World (fc01ae6d-8ed3-4872-9cef-d2199d52d61c)
      India (c8a43f13-5ea1-45f2-b46d-3a1986a1cbd7)
            Mumbai (ad491ed9-c21c-46d9-896c-c0d148957c60)
            Delhi (c195b6e0-9062-446a-9af1-8ec1a642fede)
      France (17587ed2-8433-45a4-9f4b-6825164fcd09)
            Paris (01031cfe-2492-47f1-8723-45c63ef70ec9)
            Lyon (3b2137a9-3c3a-4676-a50a-14f72ab29175)

All restaurants in Mumbai

All restaurants in the World

All restaurants in India

All restaurants in India, including India itself
owstaxIdLocation:"GPP|#c8a43f13-5ea1-45f2-b46d-3a1986a1cbd7" AND owstaxIdLocation:"GP0|#c8a43f13-5ea1-45f2-b46d-3a1986a1cbd7"

All restaurants which has a tagged location

All items not tagged from a term set in a list
The clue is to add enough including terms to what you want, and then exclude the taxonomy column based on the term set id.

-owstaxIdLocation:"GTSet|#fc01ae6d-8ed3-4872-9cef-d2199d52d61c" contentclass:STS_ListItem ListID:72b79215-34e1-43fc-8cd5-16d594872aeb

Boost restaurants tagged with Delhi, if the users location is Delhi, and also boost restaurants which are not tagged at all
See Advanced Query Operators for more information on using XRANK and SharePoint Query Variables for information on Query Variables. This sample was inspired by a conversation I had with Unni Løland.

(({searchTerms}) {?XRANK(cb=1) owstaxIdLocation:{User.SPS-Location}} ) {?XRANK(cb=1) -owstaxIdLocation:"GTSet|#fc01ae6d-8ed3-4872-9cef-d2199d52d61c"}


Topic: Article

Sign in with

Or register