Unless otherwise noted, changes described below apply to the newest Chrome beta channel release for Android, Chrome OS, Linux, macOS, and Windows. Learn more about the features listed here through the provided links or from the list on ChromeStatus.com. Chrome 81 is beta as of February 13, 2020.
Web NFC for mobileNFC stands for Near Field Communications, a short-range wireless technology for transmitting small amounts of data, usually between a specialized NFC device and a reader. If you've scanned a badge to enter a building, you may have used used NFC.

Web NFC allows a web app to read and write to NFC tags. This opens new use cases to the web, including providing information about museum exhibits, inventory management, providing information in a conference badge, and many others.

A demonstration of Web NFC cards

Reading and writing are simple operations. You'll need a little instruction for constructing and interpreting payloads, but it's not complicated. Fortunately, we have an article, Interact with NFC devices on the web. Check it out. A few code samples are shown below.

Writing a string to an NFC tag:

if ("NDEFWriter" in window) {
 const writer = new NDEFWriter();
 await writer.write("Hello world!");
}

Scanning messages from NFC tags:

if ("NDEFReader" in window) {
 const reader = new NDEFReader();
 await reader.scan();
 reader.onreading = ({ message }) => {
 console.log(`Message read from a NFC tag: ${message}`);
 };
}

Chrome 81 introduces the mobile web to NFC with an origin trial. See the Origin Trials section for information on signing up and for a list of other origin trials starting in this release.
Augmented Reality and Hit TestingChrome 81 adds two new immersive features to the web, both designed to support augmented reality. The WebXR Device API, first enabled in Chrome 79, now supports augmented reality. We've also added support for the WebXR Hit Test API, an API for placing objects in a real-world view.

If you've already used the new API to create virtual reality, you'll be happy to know there's very little new to learn to use AR. This is because the spec was designed with the spectrum of immersive experiences in mind. Regardless of the degree of augmentation or virtualization, the application flow is the same. The differences are merely a matter of setting and requesting different properties during object creation.

The WebXR Hit Test API provides a means for an immersive experience to interact with the real world. Specifically, it enables you to place virtual objects on real-world points in a camera view. The image below from one of the Immersive Web Working Group's sample apps illustrates this. The broken blue circle indicates a point returned from the hit test API. If I tap the screen a sunflower will be placed there. The new API captures both the location of a hit test and the orientation of the point that was detected. You'll notice in the image a sunflower has been placed on both the floor and the wall.

If you're completely new to the WebXR Device API, check out our earlier articles, Virtual reality comes to the web and Virtual reality comes to the web, part II. If you're already familiar with entering a WebXR session and constructing a frame loop, then check out our new article on Web AR. Also check out our article on the WebXR Hit Test API.
Origin TrialsThis version of Chrome introduces the origin trials described below. Origin trials allow you to try new features and give feedback on usability, practicality, and effectiveness to the web standards community. To register for any of the origin trials currently supported in Chrome, including the ones described below, visit the Origin Trials dashboard. To learn more about origin trials themselves, visit the Origin Trials Guide for Web Developers.
PointerLock unadjustedMovementScripts now have the ability to request unadjusted and unaccelerated mouse movement data when in PointerLock. If unadjustedMovement is set to true, then pointer movements will not be affected by the underlying platform modifications such as mouse acceleration.
Other features in this releaseBuffered Flag for Long TasksChrome 81 updates the buffered flag of PerformanceObserver to support long tasks. In particular, this feature provides a way to gain insight into early long tasks for apps or pages that register a PerformanceObserver early.
CSS image-orientation propertyChrome will by default respect EXIF metadata within images indicating desired orientation. The accompanying image-orientation property allows developers to override this behavior.
CSS Color Adjust: color-schemeA new meta tag and CSS property lets sites opt-in to following the preferred color scheme when rendering UI elements such as default colors of form controls and scrollbars as well as the used values of the CSS system colors. For Chrome 81 only initial color and background are affected.
Exclude Implicit Tracks from grid-template-rows and grid-template-columns Resolved ValuesImplicit tracks are now excluded from the resolved values of the grid-template-rows and grid-template-columns. Previously, all tracks were included, whether implicit or explicit.
hrefTranslate attribute on HTMLAnchorElementThe HTMLAnchorElement now has an hrefTranslate attribute, providing the ability for a page to hint to a user agent's translation engine that the destination site of an href should be translated if followed.
IntersectionObserver Document RootThe IntersectionObserver() constructor now takes a Document as the 'root' argument, causing intersections to be calculated against the scrolling viewport of the document. This is primarily targeted towards observers running in an iframe. Previously, there was no way to measure intersection with the scrolling viewport of the iframe's document.
Modernized Form ControlsIn version 81, Chrome modernizes the appearance of form controls on Windows, ChromeOS, and Linux while improving their accessibility and touch support. (Mac and Android support are coming soon.) It's hoped that this will reduce the need to build custom form controls. This change is the result of collaboration between Microsoft and Google. For more information, see the recent talk at CDS or the MS blog post. For a closer look at the controls, this page gives an example of all of the elements that changed.
Move onwebkit{animation,transition}XX handlers to GlobalEventHandlersUntil now, the prefixed onwebkit{animation,transition}XX handlers were only available on the Window object in Chrome. They are now on HTMLElement and Document as required by the spec. This fix brings Chrome in line with Gecko and Webkit.

Note: This change is intended to improve interoperability on existing web pages. These handlers are still obsolete so web developers should use the non-refixed versions on new pages.
Position State for Media SessionAdds support for tracking position state in a media session. The position state is a combination of the playback rate, duration, and current playback time. This can then be used by browsers to display position in the UI and with the addition of seeking can support seeking/scrubbing too. For a code sample and demonstration, see our sample.

SubmitEventChrome now supports a SubmitEvent type, an Event subtype which is dispatched on form submission. The SubmitEvent has a submitter property that refers to attributes of the submitter button including the entry data, the formaction attribute, the formenctype attribute, the formmethod attribute, and the formtarget attribute.

Currently, applications are doing their own form submission by calling preventDefault() during onsubmit. This approach has the limitation that the received event does not include the button that triggered the submission.
WebAudio: ConvolverNode.channelCount and channelCountModeFor a ConvolverNode, the channelCount can now be set to 1 or 2. The channelCountMode can be "explicit" or "clamped-max". Previously, a channelCount of 1 was not allowed and neither was a mode of "explicit".

This release also extends ConvolverNode capabilities slightly to allow developers to choose the desired behavior without having to add a GainNode to do the desired mixing.
WebRTC

RTCPeerConnection.onicecandidateerror event changes

The candidateerror event now has an explicit address and port, replacing hostCandidate.

onclosing Event for RTCDataChannel

Adds the onclosing event to the RTCDataChannel object, which signals to the user of a data channel that the other side has started closing the channel. The user agent will continue reading from the queue (if it contains anything) until the queue is empty, but no more data can be sent.
WorkerOptions for shared workers constructor Adds the WorkerOptions object as the second argument for a shared worker constructor. The previous second argument, a string containing the worker's name is still supported.
WritableStream.close()WritableStream objects now have a close() method that closes a stream if it is unlocked. This is directly equivalent to getting a writer, using the writer to close the stream, and then unlocking it again.
JavaScriptThis version of Chrome incorporates version 8.1 of the V8 JavaScript engine. It specifically includes the changes listed below. You can find a complete list of recent changes in the V8 release notes.
Intl.DisplayNames()The Intl.DisplayNames() object lets an app or script get localized names of language, script, currency codes, and commonly used names of date fields and symbols. This will reduce the size of apps (thereby improving latency), make it easier to build internationalized UI components, reduce translation costs, and provide more consistent translations across the web.
Deprecations, and RemovalsThis version of Chrome introduces the deprecations and removals listed below. Visit ChromeStatus.com for lists of current deprecations and previous removals.
Deprecation and Remove "basic-card" support Payment HandlerThis version of Chrome removes the basic-card polyfill for Payment Request API in iOS Chrome. As a result, the Payment Request API is temporarily disabled in iOS Chrome. For full details, see Rethinking Payment Request for iOS.
Remove supportedType field from BasicCardRequestSpecifying "supportedTypes":[type] parameter for "basic-card" payment method shows cards of only the requested type, which is one of "credit", "debit", or "prepaid".

The card type parameter has been removed from the spec and is now removed from Chrome, because of the difficulty of accurate card type determination. Merchants today must check card type with their PSP, because they cannot trust the card type filter in the browser:

• Only issuing banks know the card type with certainty and downloadable card type databases have low accuracy, so it's impossible to know accurately the type of the cards stored locally in the browser.
• The "basic-card" payment method in Chrome no longer shows cards from Google Pay, which may have connections with issuing banks.

Firefox removed "supportedTypes" in version 65.
Remove the <discard> elementChrome 81 removes the <discard> element. It is only implemented in Chromium, and is thus not possible to use interoperably. For most use cases it can be replaced with a combination of animation of the 'display' property and a removal (JavaScript) callback/event handler.
Remove TLS 1.0 and TLS 1.1This version of Chrome removes TLS 1.0 and TLS 1.1. TLS (Transport Layer Security) is the protocol which secures HTTPS. It has a long history stretching back to the nearly twenty-year-old TLS 1.0 and its even older predecessor, SSL. Both TLS 1.0 and 1.1 have a number of weaknesses.

• TLS 1.0 and 1.1 use MD5 and SHA-1, both weak hashes, in the transcript hash for the Finished message.
• TLS 1.0 and 1.1 use MD5 and SHA-1 in the server signature. (Note: this is not the signature in the certificate.)
• TLS 1.0 and 1.1 only support RC4 and CBC ciphers. RC4 is broken and has since been removed. TLS's CBC mode construction is flawed and was vulnerable to attacks.
• TLS 1.0's CBC ciphers additionally construct their initialization vectors incorrectly.
• TLS 1.0 is no longer PCI-DSS compliant.

Supporting TLS 1.2 is a prerequisite to avoiding the above problems. The TLS working group has deprecated TLS 1.0 and 1.1. Chrome deprecated these features in version 72 in early 2019.
TLS 1.3 downgrade hardening bypassTLS 1.3 includes a backwards-compatible hardening measure to strengthen downgrade protections. However, when we shipped TLS 1.3 last year, we had to partially disable this measure due to incompatibilities with some non-compliant TLS-terminating proxies. Chrome currently implements the hardening measure for certificates which chain up to known roots, but allows a bypass for certificates chaining up to unknown roots. We intend to enable it for all connections.

Downgrade protection mitigates the security impact of the various legacy options we retain for compatibility. This means user's connections are more secure and, when security vulnerabilities are discovered, it is less of a scramble to respond to them. (That, in turn, means fewer broken sites for users down the road.) This also aligns with RFC 8446.