Windows Search problems, part 1: TypeScript files and extension collisions

You know a piece of text exists in a file. Your editor finds it immediately. Windows Search does not. Yet searching for the file’s name works perfectly.

That is a useful distinction: Windows may know where a file is without knowing what is inside it.

In this first part of a series about Windows Search problems, I want to look at file extensions. TypeScript makes a particularly interesting example because its extensions overlap with those used for video. The overlap is real; whether it causes a search problem depends on your indexing configuration.

One extension, two very different files

For a developer, example.ts probably means TypeScript source code. For someone working with video, it can mean an MPEG transport stream. The same ambiguity applies to .mts: TypeScript uses it for explicitly marked ECMAScript modules, while video tools also recognize it as a transport-stream extension.

These are documented uses, not just unusual filenames. The TypeScript 4.7 release notes introduce .mts and .cts, which emit .mjs and .cjs respectively. FFmpeg’s MPEG-TS muxer lists ts, m2t, m2ts, and mts among its extensions.

An extension is a convention. It does not guarantee that every file ending in those letters contains the same kind of data.

This becomes important when software needs to extract information from the file, rather than simply list its name.

What Windows Search needs to know

There are three questions worth keeping separate:

1. Is the file’s location included in indexing?
2. Is this file type configured for properties only, or for properties and contents?
3. Is a suitable content filter available for the file?

Windows Search uses components called filter handlers, implementing the IFilter interface, to extract content for its full-text index. Microsoft documents that the filtering process selects a registered handler using the item’s class, perceived type, or filename extension. Installed applications can affect the available handlers. See Understanding filter handlers in Windows Search.

That gives extension collisions a plausible route to trouble: a handler associated with an extension may not be suitable for every file using it. It does not establish that Windows always sends TypeScript to a video parser. That requires checking the configuration on the machine in question.

Likewise, having .ts listed among indexed file types does not establish that TypeScript source text is being extracted successfully.

Check the settings before changing them

Open Indexing Options through Windows Settings or Control Panel. The route varies between Windows versions. Microsoft’s search indexing guide describes the available settings.

Check Modify for the locations included in indexing. Then open Advanced > File Types and inspect ts and mts separately.

Record whether each extension is enabled, its displayed filter description, and the selected indexing mode:

• Index Properties Only supports looking up information such as the filename, without making the file’s body searchable through the index.
• Index Properties and File Contents requests content indexing as well; successful extraction still depends on the file and its handler.

Keep a screenshot of the original settings. It makes comparison and restoring your previous configuration easier.

Also separate the application that opens a file from the component that indexes it. Making your editor the default application for .ts files is not proof that Windows Search can read their source text.

A small test you can repeat

Before changing a whole development workspace, test a few files in a folder explicitly included in indexing.

Create probe.txt, probe.ts, and probe.mts. Save all three as UTF-8 text with exactly the same contents:

// szeweqsearchprobe
export const answer = 42;

The unusual word is a search marker. Keep it out of the filenames so that finding it requires looking inside the files.

Wait until Indexing Options reports that indexing is complete. In File Explorer, open the test folder and try two searches:

1. Search for probe to check whether the files can be found by name.
2. Search for content:szeweqsearchprobe to look for the marker inside them.

Record which files appear in each search. Repeat after any indexing change, allowing the affected files to be processed again.

The .txt file is a control. If its contents are found but the TypeScript files’ contents are not, you have narrowed the investigation toward differences in file-type settings or extraction. If none of the files appear, check location coverage and indexing status first.

File Explorer can also search without relying on an existing index in some circumstances. A successful result alone therefore does not prove that a particular filter populated the index. Treat this as a practical check of search behavior, with the settings and location recorded alongside it. It does not provide a complete trace of the indexing pipeline.

Keep the results with your settings screenshots: together, they give you a baseline for the next change.

My recommendation for developers: disable TypeScript indexing

If you search your code through your editor and do not need TypeScript files in Windows Search, I recommend disabling indexing for them. This is especially worth trying on web projects with large dependency trees and frequently changing source files.

When those files are inside indexed locations, excluding them removes work from the indexer. Windows Search does not need to maintain an index of code you already search elsewhere. How much this helps depends on how many matching files are indexed and how often they change.

To disable indexing for TypeScript files:

1. Open Indexing Options.
2. Select Advanced > File Types.
3. Uncheck ts and mts. Also uncheck tsx and cts if your projects use those extensions and you do not need them in Windows Search.
4. Apply the changes and let Windows finish updating the index before comparing its behavior.

Unchecking an extension excludes those files from the index, including their filenames. Your editor can still search the files directly, but Windows Search’s indexed results will no longer include them. You can restore indexing by checking the extensions again.

If you want Windows Search to keep finding source files by name, leave the extensions checked and select Index Properties Only instead. This keeps filename and property indexing while avoiding source-content indexing. Microsoft’s configuration guide explains both options.

There is another complication with .ts and .mts: extension-level settings do not express “source code in this folder, video in that folder.” Before applying a broad change, consider both uses of the extension on your machine.

For mixed collections or projects where you want more control, excluding specific development folders is another option. It avoids applying the same extension rule to unrelated files elsewhere on your PC.

Missing results and slow searches are different problems

An extension collision is worth investigating when file contents are missing from results. It is not, by itself, evidence of a performance problem.

Disabling TypeScript indexing is a practical way to reduce unnecessary indexing work when your development folders are included. It will not change much if those folders were already excluded.

Compare CPU and disk activity during the same development tasks before and after the change. Test search responsiveness separately, keeping the files, search terms, and indexing state comparable. A large improvement on one workspace is useful evidence for that setup, not a guaranteed result for every developer.

Where this leaves us

When Windows finds a file’s name but misses a word inside it, inspect location coverage, indexing mode, and content extraction separately. A familiar extension is not enough to tell you what the index contains.

The next part of this series will focus on fonts: how Windows Search treats font files, what it can extract from them, and whether desktop and web font formats receive different indexing treatment.