FlaUInspect and the habit of looking at a UI the way automation sees it
Inspect tool to inspect UIs from an automation perspective
At a glance
- What is it?
- FlaUInspect is a Windows inspector for UI Automation trees, built on the FlaUI library, that shows a control the way a test would address it rather than the way a person sees it. Its most recent release adds a find panel, and its history is a story of a tool rewritten twice.
- Who is it for?
- FlaUInspect fits a test engineer who needs to identify a control the way a UI Automation selector will, and who wants to move between the visual app and the automation tree in one tool. It is the wrong choice if you need a design review of a rendering, since it shows the accessibility tree rather than the pixels, and it is the wrong choice if your application does not expose a usable automation tree, because the tree is the input here.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 70 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
An inspector that shows the tree, not the pixels
FlaUInspect is described as an inspect tool to inspect UIs from an automation perspective, and that phrase is the whole design brief.
There are various tools around that help inspecting an application that should be UI tested or automated, and the README names some of them: VisualUIAVerify, Inspect, UISpy, and probably others. The judgement it offers on those is that most of them are old and sometimes not very stable, and if open source, a code mess to maintain. FlaUInspect is supposed to be a modern alternative, based on the FlaUI library.
So the tool is not a visual debugger. What it shows is the UI Automation tree, the hierarchy of elements that Windows exposes to assistive technology and to automation frameworks, with the properties an automation client would read: AutomationId, Name, ClassName, ControlType, and the bounding rectangle. The value of that view is that it is the same view your test code will have.
That is a genuinely different perspective from the one a developer has while building the application. A developer sees a button labelled Save. An automation engineer sees a Button control with a Name property, a possibly empty AutomationId, a ClassName, and a rectangle on screen, and it is the combination of those that has to be unique enough to address reliably. FlaUInspect puts the two views next to each other so that a selector can be written against what the tool reports rather than against what the screen appears to show.
The project is C#, MIT licensed, the default branch is main, and the topics are inspect, uia and uiautomation. The last push was on 2026-08-14, and the repository is not archived. The recent releases are v2.0.0 in September 2025, v3.0.0 in January 2026 and v3.1.0 in August 2026.
Hover, selection and focus tracking are three different questions
The main screen has a set of tool buttons, and the README's table explains each one, and the distinctions are not cosmetic.
Hover Mode selects the item the mouse is over immediately when the control is pressed. Selection Mode highlights the item in the tree on screen, which is the reverse direction, from the tree back to the application. Focus Tracking always automatically selects the focused element, which is the third path, following keyboard focus rather than the mouse.
Three modes means three different questions you can be asking. Which element is under the pointer. Which element does this selector resolve to. And which element currently has keyboard focus. A control can answer all three differently, and the mismatch between them is a common source of flaky tests, so having all three available in one tool is the practical point of the design.
There is a fourth button, Show XPath, which enables a simple XPath for the currently selected element in the status bar. The word simple is doing some work there, and it is worth checking how the generated expression compares to what your framework accepts before you paste it into a test.
The 3.0.0 release added a redesign of the property grid, the control tree and the menu buttons, and a mouse hover control selection, and it fixed and redesigned the 3-state highlight of the selected control. The 2.0.0 release notes are more specific still: a third selection state was added, highlighting the selected control in an application, and a refresh button for each item in the tree was included, with refined icons, and the property grid was redesigned so that collapsed groups remain collapsed after selecting another control.
That last detail is a small usability decision with a large effect on an inspection session, since an inspector where every selection expands the whole tree is one you stop using halfway through.
UIA2 or UIA3, and why you cannot have both at once
The single most consequential decision in FlaUInspect happens before you inspect anything, and it is forced on you.
On startup of FlaUInspect you can choose whether you want to use UIA2 or UIA3, and the README links to a FAQ in the FlaUI repository explaining why you cannot use both at the same time. If you want a version of UIA in particular, you can use the pre-built FlaUInspect.UIA2 and FlaUInspect.UIA3 builds.
The distinction is about which version of the UI Automation client API the tool talks to. The two APIs are not the same interface, and a process exposes one of them, so an inspector built against one cannot read the other. That is why the choice is made at startup rather than being a setting, and why the 2.0.0 release deployed three separate applications, FlaUInspect, FlaUInspect.UIA2 and FlaUInspect.UIA3, with the UIA selection hardcoded, plus a default build that lets you choose on startup.
The 3.1.0 release moved the UAI2/UAI3 selection into settings, so the current build keeps the choice in one place rather than requiring three binaries, but the constraint that one process means one API version has not changed.
That constraint is worth understanding before you pick a build, because it decides what you can inspect. An application that only exposes the older client API cannot be inspected by the UIA3 build, and the other way around, and discovering that after installing the wrong one is a wasted afternoon.
The find panel turns the tree into a query tool
The 3.1.0 release, released on 2026-08-14, added a find panel by different properties to the Process View, and this is the feature that pushes FlaUInspect from being a viewer towards being a search tool.
The find panel in Process View allows you to find controls by different properties. It is possible to find controls by AutomationId, Name, ClassName, ControlType and XPath. The search is case insensitive and supports wildcards.
Those five properties are exactly the ones that show up in a UI Automation selector, and the case-insensitivity plus wildcards are what make it usable against a real application where the Name of a menu item differs in case from the one you remember, or where you know the beginning of an AutomationId but not the end. Finding a control by XPath is the same operation your test framework will perform, so the panel doubles as a way of checking whether a locator is unique before you commit it.
The 3.1.0 release also added an Auto Close On Process Exit option to settings, which allows automatically closing the Process View when the attached process is closed, and fixed the tooltips foreground and background color in the dark theme. That last fix is the sort of thing that only matters once you have switched to the dark theme, and it is a sign of what 3.0.0 introduced, dark and light theme support along with a new UI and a settings implementation.
The 3.0.0 release also changed how you pick the target application. The main window now displays the application and allows you to select it from a list, or you can press and hold the Find window button and drag the mouse over applications, in which case FlaUInspect highlights the application under the mouse cursor and selects its id in the list. Using a separated window for the process and a new application selection bounding were part of the same major update, alongside improved performance.
Installing means a zip, and the 2.0.0 rewrite explains the churn
The installation section is short. To install FlaUInspect, you either build it yourself or get the zip from the releases page on GitHub, and the 3.1.0 and 3.0.0 release announcements both link directly to their own release tags.
There is no package manager entry, no installer, and no documented build command in the README. What the repository does contain is a build.cake file, which is the Cake build script convention for .NET projects, so a .NET developer will recognise the setup even though the README does not spell out the invocation. The source lives under src, and the FLAUIInspect.png screenshot referenced at the top of the README is at src/FlaUInspect/FlaUInspect.png, which is the path a developer would look in.
The 2.0.0 release explains why the tool has changed shape twice. It was a complete rewrite of the application, with a new UI, new features, much more stability, based on .NET 8, and three separate versions for UIA2 and UIA3 and a default with choosing on startup.
So the current version is the second rewrite. If you find an older tutorial with screenshots that do not match, that is the explanation, and the CHANGELOG.md and the release announcements in the README are the places to check what changed between the versions you are reading about and the one you would install.
There is also a VERIFICATION file at the repository root, alongside a FlaUInspect.drawio diagram and an SVG logo, which suggests the project keeps some verification or test artefact next to the source.
Where FlaUInspect is the wrong tool
The first wrong case is design review. FlaUInspect shows the accessibility tree. It will not tell you whether a control overlaps another, whether a colour contrast is right, or whether a layout breaks at a given window size, because the tree is a semantic description and not a rendering. For anything visual, a screenshot tool or the app itself is the instrument.
The second wrong case is an application that exposes a poor automation tree. The tool shows what Windows exposes, and a lot of applications built with custom-drawn interfaces expose very little. If the tree is empty or flat, FlaUInspect cannot show you more than exists, and no amount of inspecting will produce a reliable selector.
The third wrong case is a workflow that needs both API versions at once, which the FAQ explains is not possible. If your estate contains applications that split across UIA2 and UIA3, you need both builds and you need to know which is which, and the tool will not merge the two views for you.
The alternative worth naming is the Windows SDK tooling, specifically the older Inspect and UISpy applications that FlaUInspect names as its predecessors. The difference in approach is that FlaUInspect is a modern rewrite of the same idea, built on a maintained library, with themes, a find panel and a redesigned tree, and it is a C# application you install as a zip. The old tools are what they always were, unmaintained, sometimes unstable, and in the case of the open source ones a code mess to maintain, as the README puts it. So if you already have a working Inspect or UISpy setup and its output matches what your framework needs, FlaUInspect is an upgrade in ergonomics rather than in capability. If you are starting fresh, or your framework needs XPath that the older tools do not produce, FlaUInspect is the better tool, and the switch costs a download and a re-read of the mode buttons.
Maintenance state, licence and the cost of the rewrite
The repository is not archived and the last push was on 2026-08-14, the same day as the v.3.1.0 tag. The release sequence is v2.0.0 on 2025-09-24, v3.0.0 on 2026-01-20 and v.3.1.0 on 2026-08-14, so a major release roughly every four to six months, with a point release in between.
That cadence is a consequence of the rewrite history rather than a churn problem. The 2.0.0 release was a rewrite onto .NET 8, the 3.0.0 release was a substantial redesign with a new UI, themes, settings and a separated process window, and 3.1.0 added the find panel and moved the API selection into settings. Each of those is a change that moves the tool forward rather than a bug fix, which is a different kind of release risk from a small library.
The licence is MIT, with the LICENSE file at the repository root, and the project lives under the FlaUI organisation alongside the FlaUI library it is built on. That matters more than usual here, because the tool and the automation library it exposes are the same family, so a team using FlaUI for automation gets the inspector for free in the same conceptual model.
The upgrade cost for a user is a new zip and a few minutes of relearning where the buttons moved. For a team that has written down every selector in an application under test, the cost is higher, because a rewrite can change the reported properties, and a selector that worked against the old Inspect output may need to be rechecked against FlaUInspect's tree. That is the one thing to budget for before switching an existing test suite's tooling.
Editorial conclusion
FlaUInspect fits a test engineer who needs to identify a control the way a UI Automation selector will, and who wants to move between the visual app and the automation tree in one tool. It is the wrong choice if you need a design review of a rendering, since it shows the accessibility tree rather than the pixels, and it is the wrong choice if your application does not expose a usable automation tree, because the tree is the input here. Before you rely on it, decide between the UIA2 and UIA3 builds, since the FAQ explains why both cannot be used at the same time, and check whether the XPath it shows is the form your framework's selector syntax expects.
Frequently asked questions
What is FlaUInspect used for?
FlaUInspect is an inspect tool to inspect UIs from an automation perspective, built on the FlaUI library. It shows the UI Automation tree with the properties an automation client reads, such as AutomationId, Name, ClassName and ControlType, and highlights the selected control in the running application.
How do I install FlaUInspect?
Either build it yourself from the src directory, which uses a Cake build script, or download the zip from the project's releases page on GitHub. The README documents no package manager or installer route.
What is the difference between UIA2 and UIA3 in FlaUInspect?
You choose UIA2 or UIA3 on startup, and the FlaUI FAQ explains why both cannot be used at the same time. Pre-built FlaUInspect.UIA2 and FlaUInspect.UIA3 versions exist for those who want one API hardcoded, and since 3.1.0 the selection has moved into the settings.
What can the FlaUInspect 3.1.0 find panel search by?
Controls can be found by AutomationId, Name, ClassName, ControlType and XPath. The search is case insensitive and supports wildcards.
Which modes does FlaUInspect offer for selecting a control?
Hover Mode selects the item under the mouse immediately, Selection Mode highlights the item selected in the tree on screen, and Focus Tracking always selects the focused element. A Show XPath button displays a simple XPath for the selected element in the status bar.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/flaui-flauinspect)Was this useful?