Electron.j.s Process Model: Main vs Renderer

Overview

Electron embeds both Node.js and Chromium into a single runtime. Because Chromium is multi-process by design, every Electron app is also multi-process. Two process types dominate the model: the main process and one or more renderer processes.

Main Process

There is exactly one main process per Electron app. It is the entry point — the file specified under "main" in package.json. It runs in a full Node.js environment with unrestricted access to the OS.

Responsibilities

• Creating and managing BrowserWindow instances
• App lifecycle — app.whenReady(), app.quit(), activation events
• Native OS integrations: menus, trays, dialogs, notifications, power monitor
• File system and network access via Node.js core modules
• Spawning and managing renderer processes
• Listening for IPC messages from renderers via ipcMain

const { app, BrowserWindow, ipcMain } = require('electron')
const path = require('node:path')

app.whenReady().then(() => {
  const win = new BrowserWindow({
    width: 1200,
    height: 800,
    webPreferences: {
      preload: path.join(__dirname, 'preload.js'),
      sandbox: true,           // renderer is sandboxed
      nodeIntegration: false,   // never expose Node to renderer
      contextIsolation: true,   // isolate preload world from page world
    },
  })

  win.loadFile('index.html')
})

// handle IPC from renderer
ipcMain.handle('read-config', async () => {
  return fs.readFileSync('config.json', 'utf8')
})

Renderer Process

Each BrowserWindow (and each <webview>) runs its own renderer process — an isolated Chromium render process. By default it is sandboxed: no Node.js, no direct OS access, identical security model to a Chrome tab.

What renderers can do

• Full web platform: DOM, CSS, Web APIs, WebGL, Web Workers
• Run any frontend framework (React, Vue, Svelte, etc.)
• Communicate with main via IPC through the contextBridge API surface
• Use fetch / WebSockets for network (subject to CSP)

What renderers cannot do (by default)

• Access require / Node.js built-ins
• Call Electron main-process APIs directly
• Read/write the file system
• Spawn child processes

// window.electronAPI is injected by the preload script
const config = await window.electronAPI.readConfig()
document.getElementById('output').textContent = config

Preload Scripts

Preload scripts are the controlled bridge between the two worlds. They execute in the renderer process before the page loads, but in a separate JavaScript context — they have access to Node.js and Electron APIs, while the page does not. With contextIsolation: true, the preload world and the page world are completely isolated; you must explicitly expose what you want available to the page using contextBridge.exposeInMainWorld.

const { contextBridge, ipcRenderer } = require('electron')

contextBridge.exposeInMainWorld('electronAPI', {
  // expose only specific, named operations — never expose ipcRenderer itself
  readConfig: () => ipcRenderer.invoke('read-config'),
  onUpdate: (callback) =>
    ipcRenderer.on('update-available', (_event, data) => callback(data)),
})

IPC: Inter-Process Communication

Main and renderer processes have separate memory spaces and cannot share objects directly. All communication goes through Electron's IPC layer, which serializes messages using the Structured Clone Algorithm — the same algorithm used by postMessage. Functions, prototypes, and non-serializable objects are stripped.

invoke / handle — request-response (preferred)

ipcRenderer.invoke returns a Promise that resolves when ipcMain.handle completes. This is the recommended pattern for most operations.

const result = await window.electronAPI.readConfig()
// resolves when ipcMain.handle returns

ipcMain.handle('read-config', async (event) => {
  // event.sender is the WebContents of the calling renderer
  return await fs.promises.readFile('config.json', 'utf8')
})

send / on — fire-and-forget

Use when no response is needed, or when main pushes events to a renderer unprompted.

// push to a specific renderer window
win.webContents.send('update-available', { version: '2.1.0' })

ipcRenderer.on('update-available', (_event, data) => callback(data))

Main vs Renderer — Quick Reference

Utility Process

Since Electron 21, a third process type exists: the UtilityProcess. It is a Node.js child process with access to Node APIs but no Chromium renderer context — useful for CPU-intensive work, native modules, or crash-isolated background tasks that should not block the main process.

const { utilityProcess } = require('electron')

const child = utilityProcess.fork(path.join(__dirname, 'worker.js'))

child.on('message', (msg) => console.log('from worker:', msg))
child.postMessage({ task: 'parse', payload: largeBuffer })

UtilityProcess communicates with main via postMessage/on('message'), not IPC channels. It cannot communicate with renderers directly.

Context Isolation Details

With contextIsolation: true (default since Electron 12), the preload script and the page share the same DOM but run in separate V8 contexts. Objects created in one context are not directly accessible from the other. contextBridge creates a deep-cloned, read-only proxy of whatever you expose.

// ✓ works
contextBridge.exposeInMainWorld('api', {
  getValue: () => ipcRenderer.invoke('get-value'),
  config: { theme: 'dark', version: 3 },
})

// ✗ class instances don't cross the bridge
contextBridge.exposeInMainWorld('api', new MyService()) // methods lost

Process Lifecycle

Understanding when processes start and end matters for resource management and crash handling.

• Main process starts when the OS launches the Electron binary. app.quit() or closing all windows (on non-macOS) ends it.
• Renderer process is created by new BrowserWindow() or new BrowserView(). It is destroyed when the window closes or win.destroy() is called.
• Crash recovery: renderer crashes (e.g. GPU crash) emit render-process-gone on the WebContents object. The main process can respond by reloading the window without restarting the whole app.

win.webContents.on('render-process-gone', (event, details) => {
  console.error('renderer crashed:', details.reason)
  win.reload()
})