# Chromium Embedded Framework: embedding Chromium in native apps without shipping a browser

> CEF is a BSD-licensed C and C++ framework that wraps Chromium and Blink behind stable APIs, release branches and binary distributions. It suits native applications that need an HTML5 browser control, an off-screen renderer or a Web-technology shell, and it costs you a Chromium-scale build pipeline.

**chromiumembedded/cef** — Chromium Embedded Framework (CEF). A simple framework for embedding Chromium-based browsers in other applications.

- Repository: https://github.com/chromiumembedded/cef
- Website: https://chromiumembedded.github.io/cef/
- Stars: 4,814 · Forks: 666
- Language: C++
- License: NOASSERTION
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/chromiumembedded-cef

## What CEF solves that a plain Chromium checkout does not

Chromium is built to produce Google Chrome. CEF exists for the opposite case: a third-party application that wants a browser inside it. The README frames the split directly, saying CEF focuses on facilitating embedded browser use cases while Chromium focuses mainly on Google Chrome application development. That difference is not cosmetic. A team that starts from Chromium source inherits an application, a build system and a release cadence designed for a product they are not shipping. CEF replaces that with C and C++ interfaces exposed through native libraries, so the host application talks to a stable API surface instead of to Chromium and Blink internals.

The intended audience is narrow but deep. The README lists four use cases: an HTML5-compliant browser control inside an existing native application, a lightweight native shell hosting a Web-technology UI, off-screen rendering for applications with their own drawing frameworks, and a host for automated testing of Web properties. Each of those assumes you already have a native program with its own window, event loop and drawing code. If you do not, CEF is a heavy answer to a question you have not asked.

The project dates to 2008 and was founded by Marshall Greenblatt. The README states there are over 100 million installed instances embedded in products across many industries, and points to the CEF Wikipedia page for a partial list of companies and products. That number is the project's own claim, not an independent measurement, but it explains why the API compatibility guarantees matter more here than in a typical library: a breaking change propagates into a very large installed base.

## How CEF sits between your application and Blink

The architecture is a layering problem. Chromium and Blink sit at the bottom. CEF wraps them and exposes C and C++ interfaces through native libraries, which the README describes as insulating the host application from Chromium and Blink implementation details. Your application sits on top and never links against Chromium directly.

Integration runs in both directions. The README states that CEF provides close integration between the browser and the host application, including support for custom plugins, protocols, JavaScript objects and JavaScript extensions. It also states that the host application can optionally control resource loading, navigation, context menus and printing. Read that list as the boundary of the contract: these are the extension points CEF commits to, and everything below them is implementation detail you are not meant to touch.

Two other pieces of the design show up in the repository itself. The top level contains libcef and libcef_dll alongside include, which is the C API and the C++ wrapper over it, plus patch and CHROMIUM_BUILD_COMPATIBILITY.txt, which exist because CEF is an extension of Chromium rather than a fork that has drifted. The README states that CEF maintains development and release branches tracking Chromium branches. That tracking is the whole maintenance story: when Chromium moves, CEF moves with it, and your application moves on your own schedule against the branch you pinned.

Most features ship with default implementations that provide rich functionality while requiring little or no integration work. The practical consequence is that a minimal host can be small, and the cost appears later, when you need to override a default and discover how much of the surrounding machinery you now own.

## Installing CEF and building a first application

There are two ways in, and the choice determines how much of your week the build takes. Binary distributions are the fast path. The README states that they include all files necessary to build a CEF-based application, that they are stand-alone, and that they do not require downloading CEF or Chromium source code. They are published on the Downloads page at cef-builds.spotifycdn.com, and symbol files for debugging libcef are available from the same links. Source distributions are the other path, and the README points to the Branches and Building page for downloading, building and packaging CEF manually or with automated tools.

The README does not give an install command. What it gives is a starting point and a set of build entry points that exist in the repository. On Linux, the project root carries a shell script:

```bash
./cef_create_projects.sh
```

On Windows the equivalent entry point is the batch file at the same level:

```bash
cef_create_projects.bat
```

Those two scripts generate the platform build files from the project definitions. The README does not document their flags or their output paths, so treat the generated tree as the source of truth for what to compile next.

Before writing any host code, read the Tutorial page for an overview of CEF usage and then the General Usage page for architectural and usage issues. That order is stated in the README and it is not a formality. The process model is the part new integrators get wrong, and the README does not restate it. Complete API documentation lives at cef-builds.spotifycdn.com/docs/stable.html for stable releases and at the beta URL for beta releases.

If your host is not C or C++, do not start here. The README lists external projects for .Net (CefSharp), Delphi (CEF4Delphi and dcef3), Go (cef2go and energy), Java (java-cef) and Python (cefpython), and states plainly that these are not maintained by CEF, so questions and issues go to the respective maintainer.

## The process model is the part the README does not carry

CEF runs more than one process, and the README does not explain it. For the subprocess and threading rules you have to leave the repository and read the General Usage page, which the README names as the place where architectural and usage issues are discussed. This is the single largest documentation gap for a new integrator, and it is a deliberate split rather than an oversight: the README is a directory of where things live, not a manual.

The consequence is that a first build can succeed and the application can still fail, because building the binary distribution and correctly hosting the browser are different problems. Anything involving multiple processes, or the boundary between the browser process and the renderer, is documented outside the repository. Budget reading time accordingly, and treat the Tutorial and General Usage pages as required material rather than optional background.

The same applies to the API documentation split. Stable release docs and beta release docs are separate URLs, which tells you the surface changes between channels. Pin to a stable release while you are learning the framework, and move channels only when you have a reason.

## Where CEF is the wrong tool

The clearest failure mode is starting CEF for a project that has no native host. If your application is a JavaScript or TypeScript program with a desktop shell, CEF asks you to write and maintain C or C++ that exists only to hold the browser. That is work with no product behind it.

The second cost is the release cadence. CEF tracks Chromium branches, and the README describes development and release branches accordingly. Your application is therefore attached to a moving target, and every Chromium rebase is a compatibility exercise against the API surface you use. If you cannot schedule that work, you will fall behind a branch and stay there.

The third cost is size and build complexity. Binary distributions bundle a Chromium-based runtime, and source distributions put a Chromium-scale build in your pipeline. Neither is a small dependency, and the source path in particular is not something to adopt casually. The README also notes that CEF is still very much a work in progress, which is an honest statement about a project of this scope and worth reading literally.

Finally, CEF gives you a browser, not an application framework. There is no opinion about packaging, updates, installers, auto-update channels or crash reporting. Those are yours. If you were expecting a desktop application toolkit, you are looking at the wrong layer.

## CEF versus Electron, and when the external bindings win

The comparison people actually search for is Chromium Embedded Framework versus Electron, and the difference is the direction of the embedding. Electron ships a Node.js runtime and a Chromium runtime and expects your application to be written in JavaScript, with the native layer supplied by the framework. CEF does the reverse: it expects a native application to already exist and supplies the browser as a component inside it. Neither is a superset of the other.

That distinction decides most cases. If your product is a native application with an established codebase, CEF lets you add a browser control without rewriting the application in JavaScript. If your product is new and JavaScript-first, Electron gives you the runtime and the application model; CEF gives you a library and leaves the application model to you.

The external bindings are the third option, and they are often the right one. CefSharp for .Net, java-cef for Java, cefpython for Python, cef2go and energy for Go, and CEF4Delphi for Delphi all wrap the same base framework. The README is explicit that these projects are not maintained by CEF and that questions and issues should go to the respective maintainer. That is the trade: you get a language you already use, and you take a dependency whose release schedule is not the one you read about on the CEF project page. Check the binding's own activity before you commit, because the README will not tell you anything about it.

## Licence, upgrades and what maintenance actually costs

CEF is described in the README as BSD-licensed, and the repository carries LICENSE.txt at the top level. The licence field on the repository is reported as NOASSERTION, which means the hosting platform's automated classifier did not resolve a standard identifier from the files. Read LICENSE.txt yourself rather than trusting either label. There is also a CHROMIUM_BUILD_COMPATIBILITY.txt at the top level, which is the file to consult when you need to know which Chromium build a given CEF revision expects.

Because CEF is built on Chromium, the licence question does not stop at CEF's own terms. Chromium carries its own licensing, and a binary distribution bundles a Chromium-based runtime. If you are shipping a product, that is a question for your own legal review, not something this article can settle.

Upgrade cost is dominated by the branch model. You pin a CEF branch, it tracks a Chromium branch, and moving forward means moving both. The API documentation is published separately for stable and beta releases, which is a useful signal: treat stable as the default and beta as something you opt into with a reason. The repository also carries cef_api_versions.json, which is the machine-readable record of API versioning, and AI_POLICY.md and CONTRIBUTING.md, which govern how changes are submitted. If you plan to carry local patches, read CONTRIBUTING.md first, because patch is a top-level directory for a reason: CEF is an extension of Chromium, and local divergence is a maintenance commitment you are making for the life of the branch.

## Conclusion

Adopt CEF when your application is already native and you need an HTML5 browser control, an off-screen renderer, or a shell whose UI is written in Web technologies, and when a Chromium-scale build and release process is acceptable. Avoid it when you want a JavaScript-first desktop stack, when no C or C++ host exists, or when you cannot absorb the binary distribution size and the periodic Chromium rebase. Before committing, verify the branch that matches your target Chromium version on the Branches and Building page, confirm your platform has a binary distribution on the Downloads page, and read the General Usage page for the process model, because that document is where the subprocess and threading rules are stated.

## FAQ

### What is the Chromium Embedded Framework (CEF)?

It is a BSD-licensed open source framework for embedding Chromium-based browsers in other applications, founded by Marshall Greenblatt in 2008 and based on Google Chromium. It exposes C and C++ interfaces through native libraries so the host application does not deal with Chromium and Blink internals directly.

### What is the CEF subprocess?

The README does not describe the subprocess model. It directs readers to the General Usage page for architectural and usage issues, and to the Tutorial page for an overview, so that is where the process model is documented.

### Why use CEF instead of building on Chromium directly?

The README states that Chromium focuses mainly on Google Chrome application development while CEF focuses on embedded browser use cases in third-party applications. CEF offers stable APIs, release branches tracking specific Chromium releases, and binary distributions that do not require downloading CEF or Chromium source.

### Where can I find more information on chromiumembedded CEF?

The README lists the project page on GitHub, the documentation site at chromiumembedded.github.io/cef, the Tutorial and General Usage pages, the Master Build Quick-Start and Branches and Building pages, the CEF Forum for support, and the issue tracker for bugs and feature requests.

### How does Chromium Embedded Framework compare with Electron?

The materials here do not compare them. What the README establishes is the direction of embedding: CEF exposes C and C++ interfaces so a native host application can contain a Chromium-based browser, and it also points to external bindings for .Net, Delphi, Go, Java and Python that are maintained outside the CEF project.

## Sources

- [chromiumembedded/cef on GitHub](https://github.com/chromiumembedded/cef)
- [Issues](https://github.com/chromiumembedded/cef/issues)
- [Project website](https://chromiumembedded.github.io/cef/)
- [README](https://github.com/chromiumembedded/cef/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/chromiumembedded-cef