Godot WRY puts a native webview inside your Godot project

The native webview, not an embedded browser

Godot WRY is an extension for Godot 4 that gives the editor a native webview. The mechanism is that WRY is a cross-platform webview rendering library, and this extension lets you use the native webview in Godot to build browsers and interfaces with HTML, CSS and JavaScript. The distinction that matters is that this is the operating system's own webview rather than a browser engine you ship. The feature list says so in one line, use the native system native webview with no extra dependencies, and the platform table names what that means in practice: WebView2, which is Chromium based, on Windows 10 and 11, WebKit on Mac for both Intel and Apple Silicon, and WebKitGTK on Linux under X11. The project is licensed MIT, and WRY itself is licensed Apache-2.0 or MIT. The last push was on 2026-05-09 and the most recent release is v1.0.2 from 2026-01-14.

What you get inside the editor

Four capabilities are listed, and they describe the whole integration surface. You can load website URLs and local res:// files, so the webview is not restricted to assets bundled in the project. JavaScript and GDScript code integration is the feature that turns a browser widget into a real interface, because it is what lets a click in the DOM call into your game logic and lets your game push state into the page. Mouse and keyboard input events are forwarded, which is the other half of making the embedded page feel like part of the game rather than a foreign object. A demo game interface is included at examples/character_creator_ui_demo, with a recorded capture of it, which is a more useful reference than an API listing because it shows the intended division of labour between the scene and the page. The documentation site is godot-wry.doce.sh, with an API reference and in-depth guides.

Installing it three ways

The easiest route is Godot's Asset Library, where the extension is listed as asset 3426. You open your project in Godot 4.1 or later, go to the AssetLib tab at the top of the editor, search for Godot WRY, click Download on the extension, and then click Install in the configuration dialog. The second route is the GitHub releases page, where you download the latest release ZIP file, explicitly not the source code, and extract the contents into your project's addons folder, creating it if it does not exist. The third is building from source, which uses just to build the extension and move the binaries to the Godot project folder:

$ just build

The difference between the second and third routes is the one that bites people. The release ZIP contains prebuilt binaries for each platform, while a source build produces one for the machine you are on, which is why the build script is platform-aware rather than universal.

The build script is where the platform differences live

The justfile in the repository root selects the operating system and target triple before doing anything else, mapping macos to the architecture plus apple-darwin, windows to the architecture plus pc-windows-msvc, and everything else to the architecture plus unknown-linux-gnu, and it works in the rust directory. The build recipe calls a platform-specific build and then a copy step, and each platform's copy step differs in what it moves and where it puts it. On macOS the build produces a dylib that is then moved into a libgodot_wry.framework directory, with a Resources directory created and the Info.plist from assets copied in, which is what turns a bare library into something the platform will load as a framework. On Linux the copy step places libgodot_wry.so into the addons folder under godot/addons/godot_wry/bin with the target triple as a subdirectory, and on Windows it places godot_wry.dll in the same layout. The Linux and Windows builds are a single cargo build with the target triple, the locked flag and the release profile, so the dependency versions are pinned at build time.

The caveats, which are the real specification

The README lists three caveats and they are the ones to design around. The webview always renders on top, which means the embedded page cannot be occluded by scene geometry, so a web element cannot slide behind a sprite in the 3D view. Different browser engines across platforms means your HTML, CSS and JavaScript meet WebView2, WebKit or WebKitGTK depending on where it runs, so anything you rely on has to work in all three. And there are no automatic dependency checks, which on Linux means a missing WebKitGTK is discovered when the extension fails rather than when you install it, and the README states plainly that WebKitGTK is required for WRY to function on Linux and that the package name may differ by distribution. There is a further Linux note, that X11 support is the only support there, that transparency is currently not supported, with an issue reference.

What is not there yet: mobile and the browser target

The platform table is explicit about what is missing. Android is listed as planned with the Android WebView, described as Chromium based. iOS is planned with WebKit. And a browser or HTML5 target is planned with no web engine at all in the column, which is the interesting one, because a Godot project exported to the browser could in principle host the interface in an iframe. The README notes that WRY itself already has mobile support, with a link to the upstream mobile document, and says contributions to add Android and iOS support in this extension are welcome. So the gap is in the binding layer rather than in the underlying library, which is a better position to be in than the reverse, but it does mean that if your target is mobile, this extension cannot help you today.

Where Godot WRY is the wrong choice

Three cases. The first is a project that must ship on mobile, because both mobile platforms are listed as planned and the web engine that would work there is not wired up. The second is a team that wants pixel-identical rendering on every platform, since the webview is the system webview and the three engines differ, so a layout that looks right on one machine may not on another, and that is a class of bug that is hard to reproduce once it reaches users. The third is a project whose interface is already built as Godot scenes, because then you would be maintaining two ways of expressing the same UI, and the webview's on-top rendering and its own input handling make it a fairly opinionated thing to mix with scene-based input. Against the alternatives the README lists, gdcef is open source and powered by Chromium through CEF, Godot-HTML is open source and powered by Ultralight with WebKit, and godot-webview is commercial and powered by Qt6 with Chromium. The difference in approach is the engine: this project uses what the operating system already ships, the others bring their own rendering stack, which is the trade between zero extra dependencies and one consistent renderer.

Editorial conclusion

godot_wry is a good fit for a Godot team whose interface design is already done in HTML and CSS, or whose tooling expects a browser environment, and who are willing to accept that the interface is a web document rather than a scene tree. It is a poor fit for a project that must ship on Android or iOS, both listed as planned rather than supported, and a poor fit for a team that needs pixel-identical rendering across platforms. Check three things before you commit: that your target platform is in the supported list, since Linux is marked as supported with an asterisk for X11 only and without transparency, and that you have WebKitGTK installed on Linux, because the README names it as required and says there are no automatic dependency checks, that you are on Godot 4.1 or later, and that you read the caveat about the webview always rendering on top, since an overlay that cannot be occluded by scene geometry will shape your UI design decisions.

Frequently asked questions

Official sources

1. doceazedo/godot_wry on GitHub
2. License: MIT
3. Project website
4. README
5. Releases