emscripten-core · aheejin · Dec 31, 2025 · Dec 31, 2025 · Dec 31, 2025
diff --git a/docs/emcc.txt b/docs/emcc.txt
@@ -221,7 +221,7 @@ Options that are modified or new in *emcc* are listed below:
    [link] Make the output suitable for profiling. This means including
    function names in the wasm and JS output, and preserving whitespace
    in the JS output. It does not affect optimizations (to ensure that
-   performance profiles reflect production builds). Currenly this is
+   performance profiles reflect production builds). Currently this is
    the same as "-g2".
 
 "--profiling-funcs"
@@ -255,10 +255,11 @@ Options that are modified or new in *emcc* are listed below:
      "[name].wasm.js.symbols" (with ASM.js symbols)
 
 "--emit-minification-map <file>"
-   [link] In cases where emscripten performs import/export minificiton
-   this option can be used to output a file that maps minified names
-   back to their original names.  The format of this file is single
-   line per import/export of the form "<minname>:<origname>".
+   [link] In cases where emscripten performs import/export
+   minification this option can be used to output a file that maps
+   minified names back to their original names.  The format of this
+   file is single line per import/export of the form
+   "<minname>:<origname>".
 
 "-flto"
    [compile+link] Enables link-time optimizations (LTO).

diff --git a/site/source/docs/api_reference/Filesystem-API.rst b/site/source/docs/api_reference/Filesystem-API.rst
@@ -171,7 +171,7 @@ The device node acts as an interface between the device and the file system. Any
 Setting up standard I/O devices
 ===============================
 
-Emscripten standard I/O works by going though the virtual ``/dev/stdin``, ``/dev/stdout`` and ``/dev/stderr`` devices. You can set them up using your own I/O functions by calling :js:func:`FS.init`.
+Emscripten standard I/O works by going through the virtual ``/dev/stdin``, ``/dev/stdout`` and ``/dev/stderr`` devices. You can set them up using your own I/O functions by calling :js:func:`FS.init`.
 
 By default:
 

diff --git a/site/source/docs/api_reference/console.h.rst b/site/source/docs/api_reference/console.h.rst
@@ -51,6 +51,6 @@ Functions
   Prints the string using the `dbg()` JS function, which by will write to the
   console (or stdout).  Just like the `dbg()` JS function this symbol is
   only available in debug builds (i.e. when linking with `-sASSERTIONS` or
-  equivelently `-O0`).
+  equivalently `-O0`).
 
   :param utf8String: A string encoded as UTF-8.
diff --git a/site/source/docs/api_reference/emscripten.h.rst b/site/source/docs/api_reference/emscripten.h.rst
@@ -789,7 +789,7 @@ Functions
   :param int flags: See dlopen flags.
   :param void* user_data: User data passed to onsuccess, and onerror callbacks.
   :param em_dlopen_callback onsuccess: Called if the library was loaded successfully.
-  :param em_arg_callback_func onerror: Called if there as an error loading the library.
+  :param em_arg_callback_func onerror: Called if there is an error loading the library.
 
 
 Asynchronous IndexedDB API

diff --git a/site/source/docs/api_reference/html5.h.rst b/site/source/docs/api_reference/html5.h.rst
@@ -338,7 +338,7 @@ Struct
 
     A system and implementation dependent numeric code identifying the unmodified value of the pressed key; this is usually the same as ``keyCode``.
 
-    .. warning:: This attribute is deprecated, you should use the field ``key`` instead, if available. Note thought that while this field is deprecated, the cross-browser support for ``which`` may be better than for the other fields, so experimentation is recommended. Read issue https://github.com/emscripten-core/emscripten/issues/2817 for more information.
+    .. warning:: This attribute is deprecated, you should use the field ``key`` instead, if available. Note though that while this field is deprecated, the cross-browser support for ``which`` may be better than for the other fields, so experimentation is recommended. Read issue https://github.com/emscripten-core/emscripten/issues/2817 for more information.
 
 
 Callback functions
@@ -458,7 +458,7 @@ Struct
   .. c:member:: int canvasX
      int canvasY
 
-    These fields give the mouse coordinates mapped to the Emscripten canvas client area (Emscripten-specific extension; coordinates are rounded down the nearest integer).
+    These fields give the mouse coordinates mapped to the Emscripten canvas client area (Emscripten-specific extension; coordinates are rounded down to the nearest integer).
 
 
   .. c:member:: int padding
@@ -515,7 +515,7 @@ Functions
 
   Returns the most recently received mouse event state.
 
-  Note that for this function call to succeed, :c:func:`emscripten_set_xxx_callback <emscripten_set_click_callback>` must have first been called with one of the mouse event types and a non-zero callback function pointer to enable the Mouse state capture.
+  Note that for this function call to succeed, :c:func:`emscripten_set_xxx_callback <emscripten_set_click_callback>` must have first been called with one of the mouse event types and a non-zero callback function pointer to enable the mouse state capture.
 
   :param EmscriptenMouseEvent* mouseState: The most recently received mouse event state.
   :returns: :c:data:`EMSCRIPTEN_RESULT_SUCCESS`, or one of the other result values.
@@ -561,7 +561,7 @@ Struct
     double deltaY
     double deltaZ
 
-    Movement of the wheel on each of the axis. Note that these values may be fractional, so you should avoid simply casting them to integer, or it might result
+    Movement of the wheel on each of the axes. Note that these values may be fractional, so you should avoid simply casting them to integer, or it might result
     in scroll values of 0. The positive Y scroll direction is when scrolling the page downwards (page CSS pixel +Y direction), which corresponds to scrolling
     the mouse wheel downwards (away from the screen) on Windows, Linux, and also on macOS when the 'natural scroll' option is disabled.
 
@@ -794,7 +794,7 @@ Struct
 
     The `orientation <https://developer.mozilla.org/en-US/Apps/Build/gather_and_modify_data/responding_to_device_orientation_changes#Device_Orientation_API>`_ of the device in terms of the transformation from a coordinate frame fixed on the Earth to a coordinate frame fixed in the device.
 
-    The image (source: `dev.opera.com <http://dev.opera.com/articles/view/w3c-device-orientation-api/>`_) and definitions below illustrate the co-ordinate frame:
+    The image (source: `dev.opera.com <http://dev.opera.com/articles/view/w3c-device-orientation-api/>`_) and definitions below illustrate the coordinate frame:
 
       - :c:type:`~EmscriptenDeviceOrientationEvent.alpha`: the rotation of the device around the Z axis.
       - :c:type:`~EmscriptenDeviceOrientationEvent.beta`: the rotation of the device around the X axis.
@@ -1767,7 +1767,7 @@ Functions
   .. note::
 
      Gamepad API uses an array of gamepad state objects to return the state of
-     each device. The devices are identified via the index they are present in in
+     each device. The devices are identified via the index they are present in
      this array. Because of that, if one first connects gamepad A, then gamepad
      B, and then disconnects gamepad A, the gamepad B shall not take the place of
      gamepad A, so in this scenario, this function will still keep returning two
@@ -1803,15 +1803,15 @@ Defines
 .. c:macro:: EMSCRIPTEN_EVENT_BATTERYCHARGINGCHANGE
   EMSCRIPTEN_EVENT_BATTERYLEVELCHANGE
 
-    Emscripten `batterymanager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events.
+    Emscripten `BatteryManager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events.
 
 
 Struct
 ------
 
 .. c:type:: EmscriptenBatteryEvent
 
-  The event structure passed in the `batterymanager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events: ``chargingchange`` and ``levelchange``.
+  The event structure passed in the `BatteryManager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events: ``chargingchange`` and ``levelchange``.
 
 
   .. c:member:: double chargingTime
@@ -1836,14 +1836,14 @@ Callback functions
 
 .. c:type:: em_battery_callback_func
 
-  Function pointer for the :c:func:`batterymanager event callback functions <emscripten_set_batterychargingchange_callback>`, defined as:
+  Function pointer for the :c:func:`BatteryManager event callback functions <emscripten_set_batterychargingchange_callback>`, defined as:
 
   .. code-block:: cpp
 
     typedef bool (*em_battery_callback_func)(int eventType, const EmscriptenBatteryEvent *batteryEvent, void *userData);
 
-  :param int eventType: The type of ``batterymanager`` event (:c:data:`EMSCRIPTEN_EVENT_BATTERYCHARGINGCHANGE`).
-  :param batteryEvent: Information about the ``batterymanager`` event that occurred.
+  :param int eventType: The type of ``BatteryManager`` event (:c:data:`EMSCRIPTEN_EVENT_BATTERYCHARGINGCHANGE`).
+  :param batteryEvent: Information about the ``BatteryManager`` event that occurred.
   :type batteryEvent: const EmscriptenBatteryEvent*
   :param void* userData: The ``userData`` originally passed to the registration function.
   :returns: |callback-handler-return-value-doc|
@@ -1857,7 +1857,7 @@ Functions
 .. c:function:: EMSCRIPTEN_RESULT emscripten_set_batterychargingchange_callback(void *userData, em_battery_callback_func callback)
   EMSCRIPTEN_RESULT emscripten_set_batterylevelchange_callback(void *userData, em_battery_callback_func callback)
 
-  Registers a callback function for receiving the `batterymanager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events: ``chargingchange`` and ``levelchange``.
+  Registers a callback function for receiving the `BatteryManager <http://www.w3.org/TR/battery-status/#batterymanager-interface>`_ events: ``chargingchange`` and ``levelchange``.
 
   :param void* userData: |userData-parameter-doc|
   :param em_battery_callback_func callback: |callback-function-parameter-doc|

diff --git a/site/source/docs/api_reference/index.rst b/site/source/docs/api_reference/index.rst
@@ -14,7 +14,7 @@ high level it consists of:
   Low level glue bindings for interfacing with HTML5 APIs from native code.
 
 - :ref:`console-h`:
-  Functions to writing to the console and stdout/stderr.
+  Functions for writing to the console and stdout/stderr.
 
 - :ref:`preamble-js`:
   APIs for working with compiled code from JavaScript.

diff --git a/site/source/docs/api_reference/preamble.js.rst b/site/source/docs/api_reference/preamble.js.rst
@@ -81,7 +81,7 @@ Calling compiled C functions from JavaScript
 
   Returns a native JavaScript wrapper for a C function.
 
-  This is similar to :js:func:`ccall`, but returns a JavaScript function that can be reused as many time as needed. The C function can be defined in a C file, or be a C-compatible C++ function defined using ``extern "C"`` (to prevent name mangling).
+  This is similar to :js:func:`ccall`, but returns a JavaScript function that can be reused as many times as needed. The C function can be defined in a C file, or be a C-compatible C++ function defined using ``extern "C"`` (to prevent name mangling).
 
 
   .. code-block:: javascript
@@ -239,7 +239,7 @@ Conversion functions — strings, pointers and arrays
 
 .. js:function:: intArrayFromString(stringy, dontAddNull[, length])
 
-  This converts a JavaScript string into a C-line array of numbers, 0-terminated.
+  This converts a JavaScript string into a C-like array of numbers, 0-terminated.
 
   :param stringy: The string to be converted.
   :type stringy: String
@@ -251,7 +251,7 @@ Conversion functions — strings, pointers and arrays
 
 .. js:function:: intArrayToString(array)
 
-  This creates a JavaScript string from a zero-terminated C-line array of numbers.
+  This creates a JavaScript string from a zero-terminated C-like array of numbers.
 
   :param array: The array to convert.
   :returns: A ``String``, containing the content of ``array``.

diff --git a/site/source/docs/api_reference/wasm_workers.rst b/site/source/docs/api_reference/wasm_workers.rst
@@ -117,8 +117,6 @@ If you need to synchronously wait for the posted function to finish from within
 the ``emscripten_wasm_worker_*()`` thread synchronization functions to sleep the calling thread until
 the callee has finished the operation.
 
-Note that Wasm Workers cannot 
-
 Pthreads have cancellation points
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -371,7 +369,7 @@ Both APIs allow one to spawn Web Workers from the main thread, though the semant
 
 With the Worker API, the user will be able to spawn a Web Worker from a custom URL. This URL can point to a completely separate JS file that was not compiled with Emscripten, to load up Workers from arbitrary URLs. With Wasm Workers, a custom URL is not specified: Wasm Workers will always spawn a Web Worker that computes in the same WebAssembly+JavaScript context as the main program.
 
-The Worker API does not integrate with SharedArrayBuffer, so interaction with the loaded Worker will always be asynchronous. Wasm Workers howerer is built on top of SharedArrayBuffer, and each Wasm Worker shares and computes in the same WebAssembly Memory address space of the main thread.
+The Worker API does not integrate with SharedArrayBuffer, so interaction with the loaded Worker will always be asynchronous. Wasm Workers however is built on top of SharedArrayBuffer, and each Wasm Worker shares and computes in the same WebAssembly Memory address space of the main thread.
 
 Both the Worker API and Wasm Workers API provide the user with ability to postMessage() function calls to the Worker. In Worker API, this message posting is restricted to need to originate/initiate from the main thread towards the Worker (using the API ``emscripten_call_worker()`` and ``emscripten_worker_respond()`` in ``<emscripten.h>``). With Wasm Workers however one can also postMessage() function calls to their parent (owning) thread.
 

diff --git a/site/source/docs/building_from_source/configuring_emscripten_settings.rst b/site/source/docs/building_from_source/configuring_emscripten_settings.rst
@@ -45,7 +45,7 @@ Locating the compiler configuration file (.emscripten)
 ======================================================
 
 The settings file (``.emscripten``) is created by default within the emscripten
-directory (alongsize ``emcc`` itself).  In cases where the emscripten directory
+directory (alongside ``emcc`` itself).  In cases where the emscripten directory
 is read-only the user's home directory will be used:
 
   - On Linux and macOS this file is named **~/.emscripten**, where ~ is the

diff --git a/site/source/docs/building_from_source/index.rst b/site/source/docs/building_from_source/index.rst
@@ -13,7 +13,7 @@ before it can be used (e.g. ``npm install``).  The ``bootstrap`` script in the
 top level of the repository takes care of running these steps and ``emcc`` will
 error out if it detects that ``bootstrap`` needs to be run.
 
-Emscripten comes with its own versions some C/C++ system libaries which ``emcc``
+Emscripten comes with its own versions of some C/C++ system libraries which ``emcc``
 builds automatically as and when needed (in the emsdk builds, these are precompiled).
 You can also build them manually with the ``embuilder`` tool - see ``embuilder --help``
 for more information.

diff --git a/site/source/docs/building_from_source/verify_emscripten_environment.rst b/site/source/docs/building_from_source/verify_emscripten_environment.rst
@@ -31,7 +31,7 @@ could not be found:
   shared:INFO: (Emscripten: Running sanity checks)
   emcc: warning: LLVM version for clang executable "/usr/bin/clang" appears incorrect (seeing "16.0", expected "18") [-Wversion-check]
 
-At this point you need to :ref:`Install and activate <fixing-missing-components-emcc>` any missing components. When everything is set up properly, ``emcc ---check`` should give no warnings, and if you just enter ``emcc`` (without any input files), it will give an error ::
+At this point you need to :ref:`Install and activate <fixing-missing-components-emcc>` any missing components. When everything is set up properly, ``emcc --check`` should give no warnings, and if you just enter ``emcc`` (without any input files), it will give an error ::
 
   emcc: error: no input files
 

diff --git a/site/source/docs/compiling/Building-Projects.rst b/site/source/docs/compiling/Building-Projects.rst
@@ -101,7 +101,7 @@ This list is not exhaustive, but illustrates most commonly used combinations.
 .. note::
    Regardless of the name of the output file ``emcc`` will always perform
    linking and produce a final executable, unless a specific flags (e.g. ``-c``)
-   direct it do something else.  This differs to previous behaviour where
+   direct it to do something else.  This differs to previous behaviour where
    ``emcc`` would default to combining object files (essentially assuming
    ``-r``) unless given a specific executable extension (e.g. ``.js`` or
    ``.html``).

diff --git a/site/source/docs/compiling/Dynamic-Linking.rst b/site/source/docs/compiling/Dynamic-Linking.rst
@@ -12,7 +12,7 @@ with little or no changes (see :ref:`Building-Projects`).
 
 In addition, Emscripten also has support for a form of **dynamic** linking of
 WebAssembly modules.  This can add overhead, so for best performance static
-linking should still be preferred.  However, this overhead can can be reduced
+linking should still be preferred.  However, this overhead can be reduced
 with the use of certain command line flags. See below for details.
 
 Background
@@ -127,7 +127,7 @@ the command line when you link the main module. e.g.
 
      emcc -sMAIN_MODULE main.c libsomething.wasm
 
-At runtime, the JavaScript loading code will load ``libsomthing.wasm`` (along
+At runtime, the JavaScript loading code will load ``libsomething.wasm`` (along
 with any other side modules) along with the main module before the application
 starts to run.  The running application then can access code from any of the
 modules linked together.
@@ -218,7 +218,7 @@ Limitations
 Pthreads support
 ----------------
 
-Dynamic linking + pthreads is is still experimental.  As such, linking with both
+Dynamic linking + pthreads is still experimental.  As such, linking with both
 :ref:`MAIN_MODULE` and ``-pthread`` will produce a warning.
 
 While load-time dynamic linking works without any complications, runtime dynamic
@@ -238,6 +238,6 @@ However, there there is one class of application that currently may require
 modification.  If your applications busy waits, or directly uses the
 ``atomic.waitXX`` instructions (or the clang
 ``__builtin_wasm_memory_atomic_waitXX`` builtins) you maybe need to switch it
-to use ``emscripten_futex_wait`` or order avoid deadlocks.  If you don't use
+to use ``emscripten_futex_wait`` in order to avoid deadlocks.  If you don't use
 ``emscripten_futex_wait`` while you block, you could potentially block other
 threads that are calling ``dlopen`` and/or ``dlsym``.
diff --git a/site/source/docs/compiling/Modularized-Output.rst b/site/source/docs/compiling/Modularized-Output.rst
@@ -35,7 +35,7 @@ separate and isolated instances of the same program.
 By default, the factory function is called ``Module``, but it can be given a
 unique name via the ``-sEXPORT_NAME`` setting.
 
-For example, a program is built using ``-sMODULARIZE -sEXPORT_NAME=Foo`` can
+For example, a program built using ``-sMODULARIZE -sEXPORT_NAME=Foo`` can
 be instantiated using:
 
 ::
@@ -113,11 +113,11 @@ Limitations
 -----------
 
 Some major features still do not work in this mode.  Many of these we hope to
-fix in future releses.  Current limitations include:
+fix in future releases.  Current limitations include:
 
-* Internal usage (e.g. usage within EM_JS / JS libary code) of the ``Module``
+* Internal usage (e.g. usage within EM_JS / JS library code) of the ``Module``
   global does not work.  This is because symbols are exported directly using
-  ES6 module syntax rathar than using the ``Module`` global.
+  ES6 module syntax rather than using the ``Module`` global.
 
 * The ``wasmExports`` internal global does not exist.
 
@@ -133,7 +133,7 @@ Source Phase Imports (experimental)
 ===================================
 
 `Source phase imports`_ is a JavaScript proposal that adds support for importing
-Wasm modules via ES import statements.  This allows emscripten to elide some of
+Wasm modules via ES import statements.  This allows Emscripten to elide some of
 the auto-generated code for finding and fetching the Wasm binary.
 
 See :ref:`source_phase_imports`.
@@ -146,7 +146,7 @@ ES Module Integration (experimental)
 ====================================
 
 `Wasm ESM integration`_ is a WebAssembly proposal that allows Wasm instances to
-be imported directly as ES modules.  This allows emscripten to elide a lot of
+be imported directly as ES modules.  This allows Emscripten to elide a lot of
 boilerplate code for linking up Wasm and JavaScript.
 
 See :ref:`wasm_esm_integration`.
@@ -156,7 +156,7 @@ Limitations
 
 This setting implicitly enables :ref:`export_es6` and sets :ref:`MODULARIZE` to
 ``instance``.  Because of this all the same limitations mentioned above for
-``-sMODULARIZE=intance`` apply.
+``-sMODULARIZE=instance`` apply.
 
 Some additional limitations are: