diff --git a/docs/extend/plugins_authorization.md b/docs/extend/plugins_authorization.md
index 1b0f83b510..4c87cf5d68 100644
--- a/docs/extend/plugins_authorization.md
+++ b/docs/extend/plugins_authorization.md
@@ -58,7 +58,7 @@ respectively.
 
 ## Default user authorization mechanism
 
-If TLS is enabled in the [Docker daemon](../security/https.md), the default user authorization flow extracts the user details from the certificate subject name.
+If TLS is enabled in the [Docker daemon](https://docs.docker.com/engine/security/https/), the default user authorization flow extracts the user details from the certificate subject name.
 That is, the `User` field is set to the client certificate subject common name, and the `AuthenticationMethod` field is set to `TLS`.
 
 ## Basic architecture
diff --git a/docs/extend/plugins_network.md b/docs/extend/plugins_network.md
index 9546195bbd..0e1869e4af 100644
--- a/docs/extend/plugins_network.md
+++ b/docs/extend/plugins_network.md
@@ -30,7 +30,7 @@ kind of protocol.
 ## Network driver plugins and swarm mode
 
 Docker 1.12 adds support for cluster management and orchestration called
-[swarm mode](../swarm/index.md). Docker Engine running in swarm mode currently
+[swarm mode](https://docs.docker.com/engine/swarm/). Docker Engine running in swarm mode currently
 only supports the built-in overlay driver for networking. Therefore existing
 networking plugins will not work in swarm mode.
 
diff --git a/docs/reference/builder.md b/docs/reference/builder.md
index 19e693482f..3f2118403c 100644
--- a/docs/reference/builder.md
+++ b/docs/reference/builder.md
@@ -118,7 +118,7 @@ image you can specify it with `--cache-from` option. Images specified with
 registries.
 
 When you're done with your build, you're ready to look into [*Pushing a
-repository to its registry*](../tutorials/dockerrepos.md#contributing-to-docker-hub).
+repository to its registry*](https://docs.docker.com/engine/tutorials/dockerrepos/#/contributing-to-docker-hub).
 
 ## Format
 
@@ -492,7 +492,7 @@ Or
 The `FROM` instruction sets the [*Base Image*](glossary.md#base-image)
 for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
 its first instruction. The image can be any valid image – it is especially easy
-to start by **pulling an image** from the [*Public Repositories*](../tutorials/dockerrepos.md).
+to start by **pulling an image** from the [*Public Repositories*](https://docs.docker.com/engine/tutorials/dockerrepos/).
 
 - `FROM` must be the first non-comment instruction in the `Dockerfile`.
 
@@ -1205,7 +1205,7 @@ containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
 string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
 /var/db`. For more information/examples and mounting instructions via the
 Docker client, refer to
-[*Share Directories via Volumes*](../tutorials/dockervolumes.md#mount-a-host-directory-as-a-data-volume)
+[*Share Directories via Volumes*](https://docs.docker.com/engine/tutorials/dockervolumes/#/mount-a-host-directory-as-a-data-volume)
 documentation.
 
 The `docker run` command initializes the newly created volume with any data
@@ -1698,7 +1698,7 @@ The `SHELL` feature was added in Docker 1.12.
 ## Dockerfile examples
 
 Below you can see some examples of Dockerfile syntax. If you're interested in
-something more realistic, take a look at the list of [Dockerization examples](../examples/index.md).
+something more realistic, take a look at the list of [Dockerization examples](https://docs.docker.com/engine/examples/).
 
 ```
 # Nginx
diff --git a/docs/reference/glossary.md b/docs/reference/glossary.md
index c99f18b3f4..1644600739 100644
--- a/docs/reference/glossary.md
+++ b/docs/reference/glossary.md
@@ -159,7 +159,7 @@ installs Docker on them, then configures the Docker client to talk to them.
 
 ## node
 
-A [node](../swarm/how-swarm-mode-works/nodes.md) is a physical or virtual
+A [node](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/) is a physical or virtual
 machine running an instance of the Docker Engine in swarm mode.
 
 **Manager nodes** perform swarm management and orchestration duties. By default
@@ -198,7 +198,7 @@ and its [tags](https://hub.docker.com/r/library/nginx/tags/)
 
 ## service
 
-A [service](../swarm/how-swarm-mode-works/services.md) is the definition of how
+A [service](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/) is the definition of how
 you want to run your application containers in a swarm. At the most basic level
 a service  defines which container image to run in the swarm and which commands
 to run in the container. For orchestration purposes, the service defines the
@@ -212,7 +212,7 @@ environment.
 
 ## service discovery
 
-Swarm mode [service discovery](../swarm/networking.md) is a DNS component
+Swarm mode [service discovery](https://docs.docker.com/engine/swarm/networking/) is a DNS component
 internal to the swarm that automatically assigns each service on an overlay
 network in the swarm a VIP and DNS entry. Containers on the network share DNS
 mappings for the service via gossip so any container on the network can access
@@ -224,7 +224,7 @@ automatically distributes requests to the service VIP among the active tasks.
 
 ## swarm
 
-A [swarm](../swarm/index.md) is a cluster of one or more Docker Engines running in [swarm mode](#swarm-mode).
+A [swarm](https://docs.docker.com/engine/swarm/) is a cluster of one or more Docker Engines running in [swarm mode](#swarm-mode).
 
 ## Swarm
 
@@ -239,7 +239,7 @@ works with Docker can now transparently scale up to multiple hosts.
 
 ## swarm mode
 
-[Swarm mode](../swarm/index.md) refers to cluster management and orchestration
+[Swarm mode](https://docs.docker.com/engine/swarm/) refers to cluster management and orchestration
 features embedded in Docker Engine. When you initialize a new swarm (cluster) or
 join nodes to a swarm, the Docker Engine runs in swarm mode.
 
@@ -252,7 +252,7 @@ tags are how various images in a repository are distinguished from each other.
 
 ## task
 
-A [task](../swarm/how-swarm-mode-works/services.md#tasks-and-scheduling) is the
+A [task](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/#/tasks-and-scheduling) is the
 atomic unit of scheduling within a swarm. A task carries a Docker container and
 the commands to run inside the container. Manager nodes assign tasks to worker
 nodes according to the number of replicas set in the service scale.
@@ -260,7 +260,7 @@ nodes according to the number of replicas set in the service scale.
 The diagram below illustrates the relationship of services to tasks and
 containers.
 
-![services diagram](../swarm/images/services-diagram.png)
+![services diagram](https://docs.docker.com/engine/swarm/images/services-diagram.png)
 
 ## Toolbox
 
diff --git a/docs/reference/run.md b/docs/reference/run.md
index a48b44d4bf..cd6cc513db 100644
--- a/docs/reference/run.md
+++ b/docs/reference/run.md
@@ -1253,7 +1253,7 @@ container's logging driver. The following options are supported:
 
 The `docker logs` command is available only for the `json-file` and `journald`
 logging drivers.  For detailed information on working with logging drivers, see
-[Configure a logging driver](../admin/logging/overview.md).
+[Configure a logging driver](https://docs.docker.com/engine/admin/logging/overview/).
 
 
 ## Overriding Dockerfile image defaults
@@ -1507,7 +1507,7 @@ The example below mounts an empty tmpfs into the container with the `rw`,
 
 The volumes commands are complex enough to have their own documentation
 in section [*Manage data in
-containers*](../tutorials/dockervolumes.md). A developer can define
+containers*](https://docs.docker.com/engine/tutorials/dockervolumes/). A developer can define
 one or more `VOLUME`'s associated with an image, but only the operator
 can give access from one container to another (or from a container to a
 volume mounted on the host).