WebAssembly (or webasm) is a bytecode format intended to be executed in a virtual machine inside a web browser. This allows an application to be deployed to a device with a compliant web browser without going through any installation steps. The application will run inside a secure sandbox in the web browser. This makes it appropriate for applications that do not need full access to the device capabilities, but benefits from a swift and uncomplicated installation process.

Supported target browsers and devices

Desktop

• Chrome
• FireFox
• Safari
• Edge(Chrome)

If the browser supports WebAssembly, then Qt should run.

Note: Qt has a fixed WebGL requirement, also for apps that do not use WebGL directly. Browsers often blacklist WebGL for older/unsupported GPUs.

Mobile

• Android Browser
• Mobile Safari

Note: There is currently no support for text input using the virtual keyboard. Safari currently does not support wasm modules of the size Qt produces.

Qt does not make direct use of operating system features and it makes no difference if, for example, FireFox runs on Windows or macOS. Qt does use some operating system adaptations, for example for ctrl/cmd key handling on macOS.

Supported Qt Modules

Qt for WebAssembly supports a subset of the Qt modules. The list below lists the currently tested modules. The list can be pasted as arguments to make.

module-qtbase module-qtdeclarative module-qtquickcontrols2 module-qtwebsockets module-qtsvg module-qtcharts module-qtmqtt

Other modules are untested and may work. Are not supported: QtMultimedia and QtWebView

Known issues

Refer to the wiki.

Known limitations

• Debugging: Qt debug and logging output is printed on the JavaScript console, which can be accessed via browser "Developer Tools" or similar.
• Nested event loops are not supported. Applications should not call, for example, QDialog::exec() or create a new QEventLoop object.
• Qt renders application content to a canvas element, and does not use (other) native DOM elements. This means accessibility (screen readers) are not supported and that text inputs won't trigger virtual keyboards.
• WebGL is required, even for applications which do not use OpenGL themselves. Most modern browsers support WebGL, but note that some browsers blacklist certain older GPUs. The Qt loader will detect this and display an error message.
• Child OpenGL windows are not supported. The window compositor (in the Qt for Wasm platform plugin) supports raster windows only.
• Qt will detect OpenGL support as OpenGL ES. In reality the browser will be providing WebGL. WebGL is based on ES and is very similar, but there are some incompatibilities. See WebGL and OpenGL Differences.
• Applications do not have access to system fonts. Font files must be distributed with the application, for example in Qt resources. Qt for WebAssembly itself embeds one such font.
• High-DPI and scaling: High-DPI rendering is supported, and so is setting the overall UI visual size using the browser zoom feature. Browser font size (and type) settings have no effect on Qt applications.
• There may be artifacts of uninitialized graphics memory on some Qt Quick Controls 2 components, such as checkboxes.
• Network access: the web sandbox limits network access to a subset of what is available for native apps.
  • QNetworkAccessManager http requests to the web page origin server, or to a server which supports CORS.
  • QWebScoket connections to any host.
  • TCP and UDP socked tunneling using over WebSockets using a websockify server [implemented by Emscripten, not tested].
    • Websockify v0.8.0 can be used to tunnel TCP connections with QT5.12 but it is MANDATORY to specify the base64 or binary subprotocols before calling QWebSocket::open().
    • For example:

      QWebSocket socket;

      QUrl url{QString("ws://server:port")};

      QNetworkRequest request{url};

      request.setRawHeader("Sec-WebSocket-Protocol", "binary");

      socket.open(request);

• Link-time warnings of the form: "cannot represent a NaN literal '0x7fdae4bde910' with custom bit pattern", are expected.
• Expected footprint (download size): Wasm modules as produced by the compiler can be large, but compress well.

Compression is typically handled on the web server side, using standard compression features: the server compresses automatically or picks up pre-compressed versions of the files. There's generally no need to have special handling of wasm files.