diff --git a/docs/api/browser-view.md b/docs/api/browser-view.md
index 6ed06d4be4..4ed007b794 100644
--- a/docs/api/browser-view.md
+++ b/docs/api/browser-view.md
@@ -8,7 +8,7 @@ removed in future Electron releases.
 Process: [Main](../glossary.md#main-process)
 
 A `BrowserView` can be used to embed additional web content into a
-`BrowserWindow`. It is like a child window, except that it is positioned
+[`BrowserWindow`](browser-window.md). It is like a child window, except that it is positioned
 relative to its owning window. It is meant to be an alternative to the
 `webview` tag.
 
diff --git a/docs/api/ipc-renderer.md b/docs/api/ipc-renderer.md
index abb00f99da..fb76c2d973 100644
--- a/docs/api/ipc-renderer.md
+++ b/docs/api/ipc-renderer.md
@@ -55,7 +55,7 @@ Send a message to the main process asynchronously via `channel`, you can also
 send arbitrary arguments. Arguments will be serialized in JSON internally and
 hence no functions or prototype chain will be included.
 
-The main process handles it by listening for `channel` with `ipcMain` module.
+The main process handles it by listening for `channel` with [`ipcMain`](ipc-main.md) module.
 
 ### `ipcRenderer.sendSync(channel[, arg1][, arg2][, ...])`
 
@@ -68,7 +68,7 @@ Send a message to the main process synchronously via `channel`, you can also
 send arbitrary arguments. Arguments will be serialized in JSON internally and
 hence no functions or prototype chain will be included.
 
-The main process handles it by listening for `channel` with `ipcMain` module,
+The main process handles it by listening for `channel` with [`ipcMain`](ipc-main.md) module,
 and replies by setting `event.returnValue`.
 
 **Note:** Sending a synchronous message will block the whole renderer process,
diff --git a/docs/api/remote.md b/docs/api/remote.md
index f5bc80d577..4c721e6822 100644
--- a/docs/api/remote.md
+++ b/docs/api/remote.md
@@ -32,7 +32,7 @@ When you invoke methods of a remote object, call a remote function, or create
 a new object with the remote constructor (function), you are actually sending
 synchronous inter-process messages.
 
-In the example above, both `BrowserWindow` and `win` were remote objects and
+In the example above, both [`BrowserWindow`](browser-window.md) and `win` were remote objects and
 `new BrowserWindow` didn't create a `BrowserWindow` object in the renderer
 process. Instead, it created a `BrowserWindow` object in the main process and
 returned the corresponding remote object in the renderer process, namely the
diff --git a/docs/api/sandbox-option.md b/docs/api/sandbox-option.md
index c49c4bb0ad..b67b9783df 100644
--- a/docs/api/sandbox-option.md
+++ b/docs/api/sandbox-option.md
@@ -33,7 +33,7 @@ which has access to a subset of the electron renderer API.
 
 Another difference is that sandboxed renderers don't modify any of the default
 JavaScript APIs. Consequently, some APIs such as `window.open` will work as they
-do in chromium (i.e. they do not return a `BrowserWindowProxy`).
+do in chromium (i.e. they do not return a [`BrowserWindowProxy`](browser-window-proxy.md)).
 
 ## Example
 
@@ -51,9 +51,9 @@ app.on('ready', () => {
 })
 ```
 
-In the above code the `BrowserWindow` that was created has node.js disabled and can communicate
+In the above code the [`BrowserWindow`](browser-window.md) that was created has node.js disabled and can communicate
 only via IPC. The use of this option stops electron from creating a node.js runtime in the renderer. Also,
-within this new window `window.open` follows the native behaviour (by default electron creates a `BrowserWindow`
+within this new window `window.open` follows the native behaviour (by default electron creates a [`BrowserWindow`](browser-window.md)
 and returns a proxy to this via `window.open`).
 
 It is important to note that this option alone won't enable the OS-enforced sandbox. To enable this feature, the
diff --git a/docs/api/webview-tag.md b/docs/api/webview-tag.md
index 59004990b9..c0ae25d8dc 100644
--- a/docs/api/webview-tag.md
+++ b/docs/api/webview-tag.md
@@ -577,7 +577,7 @@ Captures a snapshot of the `webview`'s page. Same as `webContents.capturePage([r
 
 Send an asynchronous message to renderer process via `channel`, you can also
 send arbitrary arguments. The renderer process can handle the message by
-listening to the `channel` event with the `ipcRenderer` module.
+listening to the `channel` event with the [`ipcRenderer`](ipc-renderer.md) module.
 
 See [webContents.send](web-contents.md#webcontentssendchannel-args) for
 examples.
@@ -773,7 +773,7 @@ Returns:
 * `disposition` String - Can be `default`, `foreground-tab`, `background-tab`,
   `new-window`, `save-to-disk` and `other`.
 * `options` Object - The options which should be used for creating the new
-  `BrowserWindow`.
+  [`BrowserWindow`](browser-window.md).
 
 Fired when the guest page attempts to open a new browser window.
 
diff --git a/docs/api/window-open.md b/docs/api/window-open.md
index 25bea577ce..13dd285ecf 100644
--- a/docs/api/window-open.md
+++ b/docs/api/window-open.md
@@ -3,7 +3,7 @@
 > Open a new window and load a URL.
 
 When `window.open` is called to create a new window in a web page, a new instance
-of `BrowserWindow` will be created for the `url` and a proxy will be returned
+of [`BrowserWindow`](browser-window.md) will be created for the `url` and a proxy will be returned
 to `window.open` to let the page have limited control over it.
 
 The proxy has limited standard functionality implemented to be