There are a few good answers to this one already, but I feel I should add, just for completeness, that the full chain doesn't always need to be presented to the client.

For our example of how this works, here's a certificate chain with FOUR(!) certificates, including the root and end-entity (note I'm not recommending such a design):

As a note you can get this properties page on any windows machine by double-clicking on a .cer format certificate file in file explorer and selecting 'certification path'

When a client visits the website, there are two ways this chain can be verified. The website can present the website, issuer and policy* certificates to the client directly. Alternatively, some clients can chase up extended properties on the certificates that provide an address to download the next certificate in the chain.

At least for Microsoft certificate clients, this certificate extension is called "Authority Information Access" (AIA), is similarly formatted to the CDP (CRL distribution point) field, and can be used to determine where the next certificate in the chain is located. You can see it on the 'details' tab of the same window that has the certification path, as below:

More info on CDP's and AIA's here.

So in this example, here's how the client verification works for a scenario where the whole chain isn't presented up front:

1. A client visits website.com over https and is presented the 'Website' certificate.
2. The client verifies this is not a trusted root and is not self-signed. Finding an AIA for the 'Issuer' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Website' certificate.
3. The client verifies that the 'Issuer' certificate is not a trusted root and is not self-signed. Finding an AIA for the 'Policy' certificate, it downloads this certificate and verifies the public key of this certificate signed the 'Issuer' certificate.
4. The client verifies that the 'Policy' certificate is not a trusted root and is not self-signed. However, it finds that the issuer of this certificate is one of the trusted roots and verifies the public key of the root certificate signed the 'Policy' certificate.

For each certificate in the chain, CDP's are checked for Certificate Revocation Lists (CRL's), to ensure there are no revocations.

If the client at any point had found a trusted certificate, the 'Website' certificate has been verified as issued by a trusted root and non-revoked. Other checks (like validity period) may still result in the certificate being invalid.

If at any point the client found a self-signed, non-trusted certificate, the 'Website' certificate has not been verified as issued by a trusted root. Normally the client will pop up a warning at this point.

Yes, this means you could potentially have a trusted certificate that was not self-signed, but it's not a common scenario.

*If the client trusts the root, it should have a copy of the root certificate already - it needs to have been manually added to the list of trusted root authorities! (this is also why some root CA's are still SHA1 and that's not a problem). HOWEVER, some websites will still present the root certificate, because some software will expect a full chain including the redundant root. Expect this kind of nonsensicalness often whenever you're dealing with software that interfaces with certificates.

Addendum - How Roots Get Trusted

While I mentioned roots being manually trusted, most of the time your trusted root certificates are going to be distributed to your machine by non-manual mechanisms, often bundled into every version of the software and/or distributed with automatic updates. Here's a list of common methods and policies for major website-interfacing certificate-using software:

1. Microsoft Trusted Root Certificate Program Updates

   You can get the latest certificate package here.

2. Active Directory Domain-based distribution (note the linked article also covers the method to manually add a trusted root to a local windows computer.)

The above methods both update the Windows OS certificate store which is used by multiple applications including IE and Edge.

3. Mozilla Root Store Policy
4. Root Certificate Policy - The Chromium Projects (incl. google chrome)

Both Mozilla and Chrome are capable of trusting certificates independently from the OS (effectively maintaining their own trusted root stores), and also subscribing to the OS trusted root store, depending on settings configured in the application and the specific OS.

Trusted CA's in app-specific root stores will be added and removed based on the auspices of their trusted root program.