Exporting projects

Why export?
Originally, Godot did not have any means to export projects. The developers would
compile the proper binaries and build the packages for each platform manually.

When more developers (and even non-programmers) started using it, and when our
company started taking more projects at the same time, it became evident that this
was a bottleneck.

On PC
Distributing a game project on PC with Godot is rather easy. Drop the Godot binary
in the same directory as the project.godot file, then compress the project
directory and you are done.

It sounds simple, but there are probably a few reasons why the developer may not
want to do this. The first one is that it may not be desirable to distribute loads
of files. Some developers may not like curious users peeking at how the game was
made, others may find it inelegant, and so on. Another reason is that the developer
might prefer a specially-compiled binary, which is smaller in size, more optimized
and does not include tools like the editor and debugger.

Finally, Godot has a simple but efficient system for creating DLCs as extra package
files.

On mobile
The same scenario on mobile platforms is a little worse. To distribute a project on
those devices, a binary for each of those platforms is built, then added to a
native project together with the game data.

This can be troublesome because it means that the developer must be familiarized
with the SDK of each platform before even being able to export. While learning each
SDK is always encouraged, it can be frustrating to be forced to do it at an
undesired time.

There is also another problem with this approach: different devices prefer some
data in different formats to run. The main example of this is texture compression.
All PC hardware uses S3TC (BC) compression and that has been standardized for more
than a decade, but mobile devices use different formats for texture compression,
such as PVRTC (iOS) or ETC (Android).

Export menu
After many attempts at different export workflows, the current one has proven to
work the best. At the time of this writing, not all platforms are supported yet,
but the supported platforms continue to grow.

To open the export menu, click the Export button:

../../../_images/export.png
The export menu will open. However, it will be completely empty. This is because we
need to add an export preset.

../../../_images/export_dialog.png
To create an export preset, click the Add� button at the top of the export menu.
This will open a drop-down list of platforms to choose from for an export preset.

../../../_images/export_preset.png
The default options are often enough to export, so tweaking them is usually not
necessary. However, many platforms require additional tools (SDKs) to be installed
to be able to export. Additionally, Godot needs export templates installed to
create packages. The export menu will complain when something is missing and will
not allow the user to export for that platform until they resolve it:

../../../_images/export_error.png
At that time, the user is expected to come back to the documentation and follow
instructions on how to properly set up that platform.

Export templates
Apart from setting up the platform, the export templates must be installed to be
able to export projects. They can be obtained as a TPZ file (which is a renamed ZIP
archive) from the download page of the website.

Once downloaded, they can be installed using the Install Export Templates option in
the editor:

../../../_images/exptemp.png
Export mode
When exporting, Godot makes a list of all the files to export and then creates the
package. There are 3 different modes for exporting:

Export all resources in the project

Export selected scenes (and dependencies)
Export selected resources (and dependencies)
../../../_images/expres.png
Export all resources in the project will export every resource in the project.
Export selected scenes and Export selected resources gives you a list of the scenes
or resources in the project, and you have to select every scene or resource you
want to export.

../../../_images/expselected.png
Exporting from the command line
In production, it is useful to automate builds, and Godot supports this with the
--export and --export-debug command line parameters. Exporting from the command
line still requires an export preset to define the export parameters. A basic
invocation of the command would be:

godot --export "Windows Desktop" some_name

This will export to some_name.exe, assuming there is a preset called "Windows
Desktop" and the template can be found. The output path is relative to the project
path or absolute; it does not respect the directory the command was invoked from.

You can also configure it to export only the PCK or ZIP file, allowing a single
export to be used with multiple Godot executables. This takes place if the target
name ends with .pck or .zip.

It is often useful to combine the --export flag with the --path flag, and to create
a dedicated export preset for automated export:

godot --path path/to/project --export "pck" game_name.pck

PCK versus ZIP pack file formats
Each format has its upsides and downsides. PCK is the default and recommended
format for most use cases, but you may want to use a ZIP archive instead depending
on your needs.

PCK format:

Uncompressed format. Larger file size, but faster to read/write.

Not readable and writable using tools normally present on the user's operating
system, even though there are third-party tools to extract and create PCK files.
ZIP format:

Compressed format. Smaller file size, but slower to read/write.

Readable and writable using tools normally present on the user's operating system.
This can be useful to make modding easier (see also Exporting packs, patches, and
mods).

Exporting for PC
The simplest way to distribute a game for PC is to copy the executables (godot.exe
on Windows, godot on the rest), compress the folder and send it to someone else.
However, this is often not desired.

Godot offers a more elegant approach for PC distribution when using the export
system. When exporting for PC (Linux, Windows, macOS), the exporter takes all the
project files and creates a data.pck file. This file is bundled with a specially
optimized binary that is smaller, faster and does not contain the editor and
debugger.

Warning

If you export for Windows with embedded PCK files, you will not be able to sign the
program, it will break.

Exporting for Android

Exporting for Android has fewer requirements than compiling Godot for it. The
following steps detail what is needed to setup the SDK and the engine.

Download the Android SDK

Download and install the Android SDK from developer.android.com.

If you install Android Studio, you need to run it once to complete the SDK setup.

Install OpenJDK 8
Download and install OpenJDK 8, newer versions do not work.

Create a debug.keystore
Android needs a debug keystore file to install to devices and distribute non-
release APKs. If you have used the SDK before and have built projects, ant or
eclipse probably generated one for you (on Linux and macOS, you can find it in the
~/.android directory).

If you can't find it or need to generate one, the keytool command from the JDK can
be used for this purpose:

keytool -keyalg RSA -genkeypair -alias androiddebugkey -keypass android -keystore

debug.keystore -storepass android -dname "CN=Android Debug,O=Android,C=US"
-validity 9999 -deststoretype pkcs12
This will create a debug.keystore file in your current directory. You should move
it to a memorable location such as %USERPROFILE%\.android\, because you will need
its location in a later step. For more information on keytool usage, see this Q&A
article.

Make sure you have adb

Android Debug Bridge (adb) is the command line tool used to communicate with
Android devices. It's installed with the SDK, but you may need to install one (any)
of the Android API levels for it to be installed in the SDK directory.
Setting it up in Godot
Enter the Editor Settings screen. This screen contains the editor settings for the
user account in the computer (it's independent of the project).

../../../_images/editorsettings.png
Scroll down to the section where the Android settings are located:

../../../_images/androidsdk.png
In that screen, the path to 3 files needs to be set:

The adb executable (adb.exe on Windows) - It can usually be found at %LOCALAPPDATA

%\Android\Sdk\platform-tools\adb.exe.
The jarsigner executable (from JDK 6 or 8) - On Windows, OpenJDK installs to a
directory like %PROGRAMFILES%\AdoptOpenJDK\jdk-8.0.252.09-hotspot\bin. On Linux, it
typically installs to a directory like /usr/bin/jarsigner. The exact path may vary
depending on the OpenJDK update you've installed and your machine's operating
system.
The debug .keystore file - It can be found in the folder where you put the
debug.keystore file you created above.
Once that is configured, everything is ready to export to Android!

Providing launcher icons

Launcher icons are used by Android launcher apps to represent your application to
users. Godot only requires high-resolution icons (for xxxhdpi density screens) and
will automatically generate lower-resolution variants.

There are two types of icons required by Godot:

Main Icon: The "classic" icon. This will be used on all Android versions up to
Android 8 (Oreo), exclusive. Must be at least 192�192 px.
Adaptive Icons: Starting from Android 8 (inclusive), Adaptive Icons were
introduced. Applications will need to include separate background and foreground
icons to have a native look. The user's launcher application will control the
icon's animation and masking. Must be at least 432�432 px.
See also

It's important to adhere to some rules when designing adaptive icons. Google Design
has provided a nice article that helps to understand those rules and some of the
capabilities of adaptive icons.

Caution

The most important adaptive icon design rule is to have your icon critical elements
inside the safe zone: a centered circle with a diameter of 66dp (264 pixels on
xxxhdpi) to avoid being clipped by the launcher.

If you don't provide some of the requested icons, Godot will replace them using a
fallback chain, trying the next in line when the current one fails:

Main Icon: Provided main icon -> Project icon -> Default Godot main icon.
Adaptive Icon Foreground: Provided foreground icon -> Provided main icon -> Project
icon -> Default Godot foreground icon.
Adaptive Icon Background: Provided background icon -> Default Godot background
icon.
It's highly recommended to provide all requested icons, and at least with the
specified resolutions. Only this way your application will look great on all
Android devices and versions.
Exporting for Google Play Store
Uploading an APK to Google's Play Store requires you to sign using a non-debug
keystore file; such file can be generated like this:

keytool -v -genkey -v -keystore mygame.keystore -alias mygame -keyalg RSA -validity

10000
This keystore and key are used to verify your developer identity, remember the
password and keep it in a safe place! Use Google's Android Developer guides to
learn more about APK signing.

Now fill in the following forms in your Android Export Presets:

../../../_images/editor-export-presets-android.png
Release: Enter the path to the keystore file you just generated.
Release User: Replace with the key alias.
Release Password: Key password. Note that the keystore password and the key
password currently have to be the same.
Your export_presets.cfg file now contains sensitive information. If you use a
version control system, you should remove it from public repositories and add it to
your .gitignore file or equivalent.

Don't forget to uncheck the Export With Debug checkbox while choosing the APK's
name.

../../../_images/export-with-debug-button.png
Optimizing the APK size
By default, the APK will contain native libraries for both ARMv7 and ARMv8
architectures. This increases its size significantly. To create a smaller APK,
uncheck either Armeabi-v 7a or Arm 64 -v 8a in your project's Android export
preset. This will create an APK that only contains a library for a single
architecture. Note that applications targeting ARMv7 can also run on ARMv8 devices,
but the opposite is not true.

Since August 2019, Google Play requires all applications to be available in 64-bit
form. This means you cannot upload an APK that contains just an ARMv7 library. To
solve this, you can upload several APKs to Google Play using its Multiple APK
support. Each APK should target a single architecture; creating an APK for ARMv7
and ARMv8 is usually sufficient to cover most devices in use today.

You can optimize the size further by compiling an Android export template with only
the features you need. See Optimizing a build for size for more information.

Exporting for Universal Windows Platform

There's no extra requirement to export an .appx package that can be installed as a
Windows App or submitted to the Windows Store. Exporting UWP packages also works
from any platform, not only from Windows.

However, if you want to install and run the app, you need to sign it with a trusted
signature. Godot supports automatic signing of packages with external tools.

Also, make sure the Publisher Name you set when exporting the package matches the
name used on the certificate.

Limitations on Xbox One

As described in the UWP documentation:

Submitted as an "App"
available memory is 1GB
share of 2-4 CPU cores
shared access of GPU power (45%)
Submitted as a "Game" (through Xbox Live Creators Program)
available memory is 5GB
4 exclusive CPU cores and 2 shared CPU cores
exclusive access to GPU power (100%)
Exceeding these memory limitations will cause allocation failures and the
application will crash.
Creating a signing certificate
This requires the MakeCert.exe and Pvk2Pfx.exe tools, which come with the Windows
SDK. If you use Visual Studio, you can open one of its Developer Prompts, since it
comes with these tools and they can be located in the path.

You can get more detailed instructions from Microsoft's documentation.

First, run MakeCert to create a private key:

MakeCert /n publisherName /r /h 0 /eku

"1.3.6.1.5.5.7.3.3,1.3.6.1.4.1.311.10.3.13" /e expirationDate /sv MyKey.pvk
MyKey.cer
Where publisherName matches the Publisher Name of your package and expirationDate
is in the mm/dd/yyyy format.

Next, create a Personal Information Exchange (.pfx) file using Pvk2Pfx.exe:

Pvk2Pfx /pvk MyKey.pvk /pi pvkPassword /spc MyKey.cer /pfx MyKey.pfx [/po
pfxPassword]
If you don't specify a password with /po argument, the PFX will have the same
password as the private key.

You will also need to trust this certificate in order to be able to install your
app. Open the Command Prompt as Administrator and run the following command:

Certutil -addStore TrustedPeople MyKey.cer

Setting up automatic signing
To setup automatic signing on export you need to go to Editor Settings > Export >
Uwp. From there you need to click on the folder for Signtool, and navigate to the
SignTool.exe file on your computer.

../../../_images/UWP_sign_tool.png
After setting that up close the editor settings, go to Project > Export, and select
the UWP preset. Under the Signing options click on the folder next to Certificate
and go to the certificate file. Then enter the pfxPassword in the password field.

../../../_images/UWP_export_signing.png
Your project will now be automatically signed on export.

If you want to sign an exported app manually run SignTool.exe and use the following
command.

SignTool sign /fd SHA256 /a /f MyKey.pfx /p pfxPassword package.appx

Installing the package
As of the Windows 10 Anniversary Update, you are able to install packages simply by
double clicking the .appx file from Windows Explorer.

It's also possible to install by using the Add-AppxPackage PowerShell cmdlet.

Note
If you want to update your already installed app, you must update the version
number on the new package or first uninstall the previous package.

Changing application icon for Windows

By default, the exported project's icon will be the Godot icon. You will most
likely want to change that for your project. There are two types of icons that can
be changed on Windows: the file icon and the taskbar icon.

Creating an ICO file

Windows does not use formats such as png or jpg for application icons. Instead, it
uses a Windows-only format called ICO. You can create your application icon in any
program but you will have to convert it to an ICO file using a program such as
GIMP.

This video tutorial goes over how to export an ICO file with GIMP.

It is also possible to convert a PNG image to an hiDPI-friendly ICO file using this
ImageMagick command:

magick convert icon.png -define icon:auto-resize=256,128,64,48,32,16 icon.ico

Changing the taskbar icon
The taskbar icon is the icon that shows up on the taskbar when your project is
running.

../../../_images/icon_taskbar_icon.png
To change the taskbar icon, go to Project ? Project Settings ? Application ? Config
? Windows Native Icon. Click on the folder icon and select your ICO file.

../../../_images/icon_project_settings.png
This setting only changes the icon for your exported game on Windows. To set the
icon for macOS, use Macos Native Icon. And for any other platform, use the Icon
setting.

Changing the file icon

Warning

There are known issues when changing the application icon in executables that embed
a PCK file. It's recommended to avoid using rcedit for now if you choose to enable
the Embed Pck option for your Windows export preset in the Export dialog.

The file icon is the icon of the executable that you click on to start the project.

../../../_images/icon_file_icon.png
Before selecting it in the export options, you will need to install an extra tool
called rcedit. You can download it here.

After downloading, you need to tell Godot the path to the rcedit executable on your
computer. Go to Editor ? Editor Settings ? Export ? Windows. Click on the folder
icon for the rcedit entry. Navigate to and select the rcedit executable.

Note

Linux and macOS users will also need to install WINE to use rcedit.

../../../_images/icon_rcedit.png
You should now have everything in place to change the file icon. To do that, you
will need to specify the icon when exporting. Go to Project ? Export. Assuming you
have already created a Windows Desktop preset, select your icon in ICO format in
the Application ? Icon field.

../../../_images/icon_export_settings.png
Note

If rcedit fails to change the icon, you can instead compile your own Windows export
templates with the icon changed. To do so, replace platform/windows/godot.ico with
your own ICO file before compiling export templates.

Once this is done, you can specify your export templates as custom export templates
in your project's Windows export preset.

Testing the result

You can now export the project. If it worked correctly, you should see this:

../../../_images/icon_result.png
Note

If your icon isn't showing up properly, on Windows 10, try clearing the icon cache.
To do so, open the Run dialog and enter ie4uinit.exe -ClearIconCache or
ie4uinit.exe -show.

Exporting packs, patches, and mods

Use cases
Oftentimes one would like to add functionality to one's game after it has been
deployed.

Examples of this include...

Downloadable Content: the ability to add features and content to one's game.
Patches: the ability to fix a bug that is present in a shipped product.
Mods: grant other people the ability to create content for one's game.
These tools help developers to extend their development beyond the initial release.

Overview of PCK files

Godot enables this via a feature called resource packs (PCK files, with
extension .pck).

Advantages:

incremental updates/patches
offer DLCs
offer mod support
no source code disclosure needed for mods
more modular project structure
users don't have to replace the entire game
The first part of using them involves exporting and delivering the project to
players. Then, when one wants to add functionality or content later on, they just
deliver the updates via PCK files to the users.

PCK files usually contain, but are not limited to:

scripts
scenes
shaders
models
textures
sound effects
music
any other asset suitable for import into the game
The PCK files can even be an entirely different Godot project, which the original
game loads in at runtime.

Generating PCK files

In order to pack all resources of a project into a PCK file open the project and go
to Project/Export and click on �Export PCK/Zip�. Also make sure to have an export
template selected while doing so.

../../../_images/export_pck.png
Another method would be to export from the command line. If the output file ends
with a PCK or ZIP file extension, then the export process will build that type of
file for the chosen platform.

Note

If one wishes to support mods for their game, they will need their users to create
similarly exported files. Assuming the original game expects a certain structure
for the PCK's resources and/or a certain interface for its scripts, then either...

The developer must publicize documentation of these expected structures/

interfaces, expect modders to install Godot Engine, and then also expect those
modders to conform to the documentation's defined API when building mod content for
the game (so that it will work). Users would then use Godot's built in exporting
tools to create a PCK file, as detailed above.
The developer uses Godot to build a GUI tool for adding their exact API content to
a project. This Godot tool must either run on a tools-enabled build of the engine
or have access to one (distributed alongside or perhaps in the original game's
files). The tool can then use the Godot executable to export a PCK file from the
command line with OS.execute(). It makes the most sense for the game to not use a
tool-build though (for security) and for the modding tools to do use a tool-enabled
engine build.
Opening PCK files at runtime
To import a PCK file, one uses a one-liner. Keep in mind, there is no error or
exception if the import fails. Instead, one might have to create some validation
code as a layer on top. The following example expects a �mod.pck� file in the
directory of the games executable. The PCK file contains a �mod_scene.tscn� test
scene in its root.

func _your_function():
ProjectSettings.load_resource_pack("res://mod.pck")
# Now one can use the assets as if they had them in the project from the start
var imported_scene = load("res://mod_scene.tscn")
Warning

By default, if you import a file with the same file path/name as one you already
have in your project, the imported one will replace it. This is something to watch
out for when creating DLC or mods (solved easily with a tool isolating mods to a
specific mods subfolder). However, it is also a way of creating patches for one's
own game. A PCK file of this kind can fix the content of a previously loaded PCK.

To opt out of this behavior, pass false as the second argument to

ProjectSettings.load_resource_pack().

Note
For a C# project, you need to build the DLL and place it in the project directory
first. Then, before loading the resource pack, you need to load its DLL as follows:
Assembly.LoadFile("mod.dll")

Summary
This tutorial should illustrate how easy adding mods, patches or DLC to a game is.
The most important thing is to identify how one plans to distribute future content
for their game and develop a workflow that is customized for that purpose. Godot
should make that process smooth regardless of which route a developer pursues.

Exporting for the Web

HTML5 export allows publishing games made in Godot Engine to the browser. This
requires support for WebAssembly and WebGL in the user's browser.

Important

Use the browser-integrated developer console, usually opened with F12, to view
debug information like JavaScript, engine, and WebGL errors.

Attention

Many browsers, including Firefox and Chromium-based browsers, will not load
exported projects when opened locally per file:// protocol. To get around this, use
a local server.

Tip

Python offers an easy method to start a local server. Use python -m http.server
8000 --bind 127.0.0.1 with Python 3 to serve the current working directory at
http://localhost:8000. Refer to MDN for additional information.

Attention

There are significant bugs when running HTML5 projects on iOS (regardless of the
browser). We recommend using iOS' native export functionality instead, as it will
also result in better performance.

WebGL 2
Until the OpenGL ES 3 renderer is removed from Godot in favor of Vulkan, HTML5
export uses WebGL 2 when the GLES3 option is selected.

Warning

Using WebGL 2 is not recommended due to its expected removal from Godot without
replacement.

WebGL 2 is not supported in all browsers. Firefox and Chromium (Chrome, Opera) are
the most popular supported browsers, Safari and Edge do not work. On iOS, all
browsers are based on WebKit (i.e. Safari), so they will also not work.

Godot's WebGL 2 renderer has issues with 3D and is no longer maintained.

Limitations
For security and privacy reasons, many features that work effortlessly on native
platforms are more complicated on the web platform. Following is a list of
limitations you should be aware of when porting a Godot game to the web.
Using cookies for data persistence
Users must allow cookies (specifically IndexedDB) if persistence of the user://
file system is desired. When playing a game presented in an iframe, third-party
cookies must also be enabled. Incognito/private browsing mode also prevents
persistence.

The method OS.is_userfs_persistent() can be used to check if the user:// file

system is persistent, but can give false positives in some cases.

Full screen and mouse capture

Browsers do not allow arbitrarily entering full screen. The same goes for capturing
the cursor. Instead, these actions have to occur as a response to a JavaScript
input event. In Godot, this means entering full screen from within a pressed input
event callback such as _input or _unhandled_input. Querying the Input singleton is
not sufficient, the relevant input event must currently be active.

For the same reason, the full screen project setting doesn't work unless the engine
is started from within a valid input event handler. This requires customization of
the HTML page.

Audio autoplay
Chrome restricts how websites may play audio. It may be necessary for the player to
click or tap or press a key to enable audio.

See also

Google offers additional information about their Web Audio autoplay policies.

HTTPClient and HTTPRequest

The HTTP classes have several restrictions on the HTML5 platform:

Accessing or changing the StreamPeer is not possible

Threaded/Blocking mode is not available
Cannot progress more than once per frame, so polling in a loop will freeze
No chunked responses
Host verification cannot be disabled
Subject to same-origin policy
Exported .html file must not be reused
Each project must generate their own HTML file. On export, several text
placeholders are replaced in the generated HTML file specifically for the given
export options. Any direct modifications to the generated HTML file will be lost in
future exports. To customize the generated file, see Custom HTML page for Web
export.

Boot splash is not displayed

The default HTML page does not display the boot splash while loading. However, the
image is exported as a PNG file, so custom HTML pages can display it.

Shader language limitations

When exporting a GLES2 project to HTML5, WebGL 1.0 will be used. WebGL 1.0 doesn't
support dynamic loops, so shaders using those won't work there.

Unimplemented functionality
The following functionality is currently unavailable on the HTML5 platform:

Threads
GDNative
C#
Clipboard synchronization between engine and operating system
Networking other than HTTPClient and WebSocketClient
Tip

Check the list of open HTML5 issues on GitHub to see if the functionality you're
interested in has an issue yet. If not, open one to communicate your interest.

Serving the files

Exporting for the web generates several files to be served from a web server,
including a default HTML page for presentation. A custom HTML file can be used, see
Custom HTML page for Web export.

The generated .html file can be used as DirectoryIndex in Apache servers and can be
renamed to e.g. index.html at any time, its name is never depended on by default.

The HTML page draws the game at maximum size within the browser window. This way it
can be inserted into an <iframe> with the game's size, as is common on most web
game hosting sites.

The other exported files are served as they are, next to the .html file, names
unchanged. The .wasm file is a binary WebAssembly module implementing the engine.
The .pck file is the Godot main pack containing your game. The .js file contains
start-up code and is used by the .html file to access the engine. The .png file
contains the boot splash image. It is not used in the default HTML page, but is
included for custom HTML pages.

The .pck file is binary, usually delivered with the MIME-type application/octet-
stream. The .wasm file is delivered as application/wasm.

Caution

Delivering the WebAssembly module (.wasm) with a MIME-type other than

application/wasm can prevent some start-up optimizations.

Delivering the files with server-side compression is recommended especially for the
.pck and .wasm files, which are usually large in size. The WebAssembly module
compresses particularly well, down to around a quarter of its original size with
gzip compression.

Export options
If a runnable web export template is available, a button appears between the Stop
scene and Play edited Scene buttons in the editor to quickly open the game in the
default browser for testing.

If a path to a Custom HTML shell file is given, it will be used instead of the
default HTML page. See Custom HTML page for Web export.

Head Include is appended into the <head> element of the generated HTML page. This
allows to, for example, load webfonts and third-party JavaScript APIs, include CSS,
or run JavaScript code.

Calling JavaScript from script

In web builds, the JavaScript singleton is implemented. It offers a single method
called eval that works similarly to the JavaScript function of the same name. It
takes a string as an argument and executes it as JavaScript code. This allows
interacting with the browser in ways not possible with script languages integrated
into Godot.

func my_func():
 JavaScript.eval("alert('Calling JavaScript per GDScript!');")
The value of the last JavaScript statement is converted to a GDScript value and
returned by eval() under certain circumstances:

JavaScript number is returned as GDScript float

JavaScript boolean is returned as GDScript bool
JavaScript string is returned as GDScript String
JavaScript ArrayBuffer, TypedArray and DataView are returned as GDScript
PoolByteArray
func my_func2():
var js_return = JavaScript.eval("var myNumber = 1; myNumber + 2;")
print(js_return) # prints '3.0'
Any other JavaScript value is returned as null.

HTML5 export templates may be built without support for the singleton to improve
security. With such templates, and on platforms other than HTML5, calling
JavaScript.eval will also return null. The availability of the singleton can be
checked with the JavaScript feature tag:

func my_func3():
if OS.has_feature('JavaScript'):
JavaScript.eval("""
console.log('The JavaScript singleton is available')
""")
else:
print("The JavaScript singleton is NOT available")
Tip

GDScript's multi-line strings, surrounded by 3 quotes """ as in my_func3() above,

are useful to keep JavaScript code readable.

The eval method also accepts a second, optional Boolean argument, which specifies
whether to execute the code in the global execution context, defaulting to false to
prevent polluting the global namespace:

func my_func4():
# execute in global execution context,
# thus adding a new JavaScript global variable `SomeGlobal`
JavaScript.eval("var SomeGlobal = {};", true)