microsoft/STL: the source repository behind MSVC's C++ Standard Library
MSVC's implementation of the C++ Standard Library.
At a glance
- What is it?
- This is Microsoft's implementation of the C++ Standard Library, the code that ships inside the MSVC toolset and Visual Studio. Reading it is useful for contributors and the curious; installing it is not how you get an STL.
- Who is it for?
- Adopt this repository as a source of truth if you ship C++ on MSVC and need to read the implementation, file conformance bugs, or prepare a patch; the CMake build currently produces only the native desktop flavor, so treat it as a developer path rather than a redistribution path. Do not clone it expecting to get a standard library for Linux, macOS, or clang, and do not expect non-Standard extensions.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What microsoft/STL actually is, and who should clone it
The README is unusually direct about this: "If you're a programmer who just wants to use the STL, you don't need this repo. Simply install the Visual Studio IDE and select the 'Desktop development with C++' workload." That sentence should decide most readers' next action. The library you compile against arrives with the MSVC toolset and the Visual Studio IDE; this repository is where that code is developed.
So the audience is narrower than the search traffic suggests. It is for people who want to report issues, comment on pull requests, follow what is being worked on, or submit fixes and features. It is also for people who want to take the code and use it in other apps and libraries, subject to the license terms. If your goal is simply to write std::vector and std::string in a Windows C++ project, cloning this changes nothing about your build.
The README also states the goals plainly: conformance, performance, usability, compatibility. Compatibility is described as binary compatibility plus source compatibility, and the text says binary compatibility generally overrides all other considerations, even conformance. That single sentence explains a large share of the decisions visible in the source.
How the code is laid out and what the build system can currently produce
The top level of the repository separates the library from its verification. stl/ holds the implementation, tests/ holds the test suites, benchmarks/ holds performance work, and tools/ holds supporting scripts. docs/ carries the Changelog, Status Chart, and Roadmap that the README links to. The submodules llvm-project and boost-math are checked out alongside, and libcxx appears among the test suites, which the README confirms: the project relies on three test suites, std, tr1, and libcxx, with libcxx fully ported to run under lit.
The build system is the part most worth understanding before you try anything. The README states that the CMake build is in progress and "currently capable of building one flavor of the STL (native desktop)". Extending it to the other flavors the MSVC toolset needs, /clr, /clr:pure, OneCore, and Spectre, is not done. Until it is, the legacy build system stays in stl/msbuild. The README is candid that those legacy files are kept in the repository even though they are unusable outside Microsoft, because they must be updated whenever source files are added, renamed, or deleted.
Continuous integration runs on Azure Pipelines and builds the STL for x64, x86, ARM64, and ARM64EC, and it strictly verifies clang-format compliance and other whitespace conventions. That formatting gate is not advisory: a patch that is correct but unformatted will not pass.
Getting the source and what the CMake build covers
The README gives no clone-to-build walkthrough, and the repository's own files are the only reliable guide to what exists. What can be said from the repository layout is that CMakeLists.txt and CMakePresets.json sit at the top level, so CMake is the intended entry point for the build that is in progress, and that llvm-project and boost-math are submodules, so a plain clone without them leaves the test and benchmark machinery incomplete. Because the README does not document a command sequence, no specific configure or build invocation is reproduced here; read CMakePresets.json to see which configurations the CMake build actually defines before assuming a flavor is supported.
What the README does commit to is the scope. The CMake build is in progress and "currently capable of building one flavor of the STL (native desktop)". The flavors the MSVC toolset needs, /clr, /clr:pure, OneCore, and Spectre, are not covered yet, which is why stl/msbuild remains in the tree. If your work touches one of those flavors, the CMake path will not get you there, and the README says as much rather than leaving it to be discovered.
For the library itself, the README's instruction is not to build anything: install the Visual Studio IDE and select the "Desktop development with C++" workload. That is the supported way to get the STL, and it is the answer for anyone whose goal is to compile code rather than to change the library.
The ABI promise is the constraint that shapes everything
The README states that VS 2026 is kept binary-compatible with VS 2015 through VS 2022, and that this restricts what can change in VS 2026 updates. The text goes further: significant changes are still possible even when other changes are impossible, and the details are promised for the Contribution Guidelines. As of the README, those guidelines are listed as "Coming soon", with the explanation that the rules live in the team's heads and need to be written down.
That is a real gap for an outside contributor. The rules that decide whether your patch is acceptable are the ones not yet published, and the ABI rules are described as possibly useful to other C++ libraries, which implies they are nontrivial. The README does carve out one exception: if a feature is added to the Working Paper, implemented, and then significantly changed before the International Standard is finalized, the team reserves the right to break binary compatibility, because /std:c++latest offers an experimental preview. Outside that case, binary compatibility generally wins.
There is a second, quieter constraint. The README says the project is wary of optimizations that improve some scenarios at the expense of others, or that make code significantly more complicated and fragile, and calls this a "complexity budget". A patch that speeds up one container by making its implementation harder to reason about is not obviously welcome.
Where microsoft/STL is the wrong tool, and what to use instead
The README lists non-goals explicitly. Porting to other platforms is one. Adding non-Standard extensions is another. Implementing Technical Specifications is a third, with the note that the team prioritizes features in the Working Paper. If you need a standard library for Linux, macOS, or a non-MSVC compiler, this repository is not the answer, and the README says so rather than leaving it implied.
The natural alternative for cross-platform work is libcxx, which is not a hypothetical here: this repository already vendors llvm-project as a submodule and runs libcxx as one of its three test suites. The difference in approach is structural. libcxx is designed to be built and used across platforms and toolchains, while this repository is scoped to the MSVC toolset, ships inside Visual Studio, and treats binary compatibility with a decade of MSVC releases as an overriding constraint. That constraint is why the CMake build can only produce the native desktop flavor today and why the legacy stl/msbuild machinery is still present.
If your problem is a missing Technical Specification component or a non-Standard extension, neither repository will hand it to you. The README's position is that such work is out of scope.
License, contribution status, and what maintenance looks like
The README says the source code is available under the Apache License v2.0 with LLVM Exception, and points to LICENSE.txt and NOTICE.txt. The repository metadata reports the license as NOASSERTION, which means GitHub's classifier did not resolve a standard identifier; the authoritative files are the two in the repository root. That combination, Apache 2.0 plus an LLVM exception, is the same pattern used by LLVM-family projects, and it is what you would read before reusing the code in another library. This is a description of what the files say, not legal advice.
The last push to the default branch was on 2026-09-21, and the most recent release listed is msvc-build-tools-14.51 from 2026-06-23. The repository is not archived. The README's migration status is a useful lens on the upgrade cost: code is done, the build system is in progress, tests are in progress, CI is in progress, contribution guidelines are coming soon, issues are in progress, and plans are in progress. That means the surface you depend on can shift. The README notes that approximately 200 active bugs live in Microsoft's internal database and are being replicated to GitHub issues manually, with the cxx20 and LWG tags complete and the bug and enhancement tags still being populated. A bug you care about may exist and simply not be filed here yet.
For upgrade cost, the Changelog is the artifact to watch, because it tracks which updates to this repository appear in each Visual Studio release. That is the mapping between a commit here and the toolset you install.
Editorial conclusion
Adopt this repository as a source of truth if you ship C++ on MSVC and need to read the implementation, file conformance bugs, or prepare a patch; the CMake build currently produces only the native desktop flavor, so treat it as a developer path rather than a redistribution path. Do not clone it expecting to get a standard library for Linux, macOS, or clang, and do not expect non-Standard extensions. Before investing time in a change, read CONTRIBUTING.md and the ABI compatibility rules it points to, then check whether the header you want to touch is inside stl/inc, because binary compatibility with VS 2015-2022 constrains what can be altered there.
Frequently asked questions
Is STL only in C++?
The README frames this repository as Microsoft's implementation of the C++ Standard Library, and the project's stated goals are conformance to the C++ Working Draft, performance, usability, and compatibility. It does note that the team sometimes refers to the C Standard Library and the ECMAScript regular expression specifications when implementing features that depend on them, but the library itself is a C++ library.
Is MSVC free to use?
The README does not discuss pricing or licensing of the toolset. It says the STL ships as part of the MSVC toolset and the Visual Studio IDE, and that users should install the Visual Studio IDE with the Desktop development with C++ workload. The repository's own source is described as available under the Apache License v2.0 with LLVM Exception.
Why is STL used?
The README does not argue for using the STL in general; it states the project's goals, which are conformance, performance, usability, and compatibility, and describes performance as one of C++'s core strengths that most C++ programs rely on. It also notes that usability work includes compiler throughput, diagnostic messages, and debugging checks, with extensive use of [[nodiscard]] attributes to help programmers avoid bugs.
What is STL programming?
In this repository the term refers to Microsoft's implementation of the C++ Standard Library, also known as the STL, which ships as part of the MSVC toolset and the Visual Studio IDE. The README distinguishes using the library, which needs only the Visual Studio IDE, from developing it, which is what this repository is for.
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/microsoft-stl)