safari mediarecorder webm

• Español – América Latina
• Português – Brasil
• Tiếng Việt
• Chrome for Developers

Record audio and video with MediaRecorder

Break out the champagne and doughnuts! The most starred Chrome feature EVER has now been implemented.

Imagine a ski-run recorder that synchronizes video with GeoLocation data, or a super-simple voice memo app, or a widget that enables you to record a video and upload it to YouTube — all without plugins.

The MediaRecorder API enables you to record audio and video from a web app. It's available now in Firefox and in Chrome for Android and desktop.

Try it out here .

The API is straightforward, which I'll demonstrate using code from the WebRTC sample repo demo . Note that the API can only be used from secure origins only : HTTPS or localhost.

First up, instantiate a MediaRecorder with a MediaStream. Optionally, use an options parameter to specify the desired output format:

The MediaStream can be from:

• A getUserMedia() call.
• The receiving end of a WebRTC call.
• A screen recording.
• Web Audio, once this issue is implemented.

For options it's possible to specify the MIME type and, in the future, audio and video bitrates .

MIME types have more or less specific values, combining container and codecs. For example:

• video/webm;codecs=vp8
• video/webm;codecs=vp9

Use the static method MediaRecorder.isTypeSupported() to check if a MIME type is supported, for example when you instantiate MediaRecorder:

The full list of MIME types supported by MediaRecorder in Chrome is available here .

Next, add a data handler and call the start() method to begin recording:

This examples adds a Blob to the recordedChunks array whenever data becomes available. The start() method can optionally be given a timeSlice argument that specifies the length of media to capture for each Blob.

When you've finished recording, tell the MediaRecorder:

Play the recorded Blobs in a video element by creating a 'super-Blob' from the array of recorded Blobs:

Alternatively, you could upload to a server via XHR, or use an API like YouTube (see the experimental demo below).

Download can be achieved with some link hacking:

Feedback on the APIs and demos

The ability to record audio and video without plugins is relatively new to web apps, so we particularly appreciate your feedback on the APIs.

• MediaRecorder implementation bug: crbug.com/262211
• Chrome: crbug.com/new
• Firefox: bugzil.la
• Demos: github.com/webrtc/samples

We'd also like to know what usage scenarios are most important to you, and what features you would like us to prioritize. Comment on this article or track progress at crbug.com/262211 .

• webrtc.github.io/samples/src/content/getusermedia/record
• simpl.info/mr (same code, easier URL for mobile!)
• Record a video and upload it to YouTube with an experimental custom <google-youtube-upload> element
• Paul Lewis's Voice Memos app now has MediaRecorder support, polyfilled for browsers that don't support MediaRecorder audio.
• Muaz Khan's MediaStreamRecorder is a JavaScript library for recording audio and video, compatible with MediaRecorder.
• Recorderjs enables recording from a Web Audio API node. You can see this in action in Paul Lewis's Voice Memos app.

Browser support

• Chrome 49 and above by default
• Chrome desktop 47 and 48 with Experimental Web Platform features enabled from chrome://flags
• Firefox from version 25
• Edge : 'Under Consideration'

w3c.github.io/mediacapture-record/MediaRecorder.html

API information

developer.mozilla.org/en/docs/Web/API/MediaRecorder_API

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License , and code samples are licensed under the Apache 2.0 License . For details, see the Google Developers Site Policies . Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2016-01-30 UTC.

JavaScript - supported Audio/Video MIME Types by MediaRecorder (Chrome, Firefox and Safari)

In this short article, we would like to show what audio and video MIME Types are supported by MediaRecorder class in Google Chrome and Mozilla Firefox based web browsers.

Simple answer:

video/webm;codecs=vp8

video/webm;codecs=vp8.0

audio/webm;codecs=opus

video/webm;codecs=vp8,opus

video/webm;codecs=vp8.0,opus

Note: presented MIME Types support tests were made in Jan 2023.

Tested environment

• Google Chome v109.0.5414.75 (on Windows 11)
• Google Chome v109.0.5414.85 (on Android 12)
• Mozilla Firefox v109.0 (on Windows 11)
• Mozilla Firefox v109.1.1 (on Android 12)
• Apple Safari [attached] (on iOS v16.3)
• Apple Safari v16.2 (on macOS 12.6.2)

Basic cases

In this section, you can find information what audio and video MIME types are supported by what web browsers.

Additional cases 

By running the below script you can check what MIME types are supported by your current web browser.

Native Advertising

Dirask - we help you to, solve coding problems., ask question..

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications You must be signed in to change notification settings

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaRecorder supported by Safari #653

JackMF commented Jan 12, 2022

chrisguttandin commented Jan 12, 2022

But if it works for you it seems to be implemented now and therefore the native implementation gets picked.

Sorry, something went wrong.

No branches or pull requests

How to enable the MediaRecorder API for Safari

Get the Learn to Code Starter Pack

Break into tech with the logic & computer science skills you’d learn in a bootcamp or university — at a fraction of the cost. Educative's hand-on curriculum is perfect for new learners hoping to launch a career.

Go to Safari → Preferences → Advanced

Go to Develop → Experimental Features

• Go to Settings → Safari → Advanced → Experimental Features
• Enable MediaRecorder

RELATED TAGS

CONTRIBUTOR

Learn in-demand tech skills in half the time

Mock Interview

Skill Paths

Assessments

Learn to Code

Tech Interview Prep

Generative AI

Data Science

Machine Learning

GitHub Students Scholarship

Early Access Courses

For Individuals

Try for Free

Gift a Subscription

Become an Author

Become an Affiliate

Earn Referral Credits

Cheatsheets

Frequently Asked Questions

Privacy Policy

Cookie Policy

Terms of Service

Business Terms of Service

Data Processing Agreement

Copyright © 2024 Educative, Inc. All rights reserved.

• Streaming Media 101
• Wowza Streaming Engine
• Live Streaming Bootcamp
• Video Quality Metrics
• AV1 encoding

About Jan Ozer

Streaming learning center where streaming professionals learn to excel.

• How to Build an Encoding Ladder: What You Need to Know

Streaming Learning Center to Host Streaming Summer Bootcamp Series

Jpeg ai is coming: what you need to know.

• Free Course On LCEVC Video-Enhancement

From SEO to AI Overviews for Content Marketers

Solveig offers free tier for zond 265 file analysis tool, webm vs. h.264: a first look.

Jan Ozer August 26, 2010 Articles Leave a comment 1,182 Views

Related Articles

June 6, 2024

June 3, 2024

May 23, 2024

May 17, 2024

This article compares H.264 to WebM, Google’s implementation of the VP8 codec, using three variables (encoding time, compressed quality, and CPU requirements) for playback on three personal computers. Here’s the CliffsNotes version of the results: Using Sorenson Squeeze to produce both H.264 and WebM, the latter definitely took longer, but there are techniques that you can use to reduce the spread to less than 25%, which is pretty much irrelevant. Though H.264 offers slightly higher quality than the VP8 codec used by WebM using the aggressive (e.g., very low data rate) parameters that I tested, at normal web parameters, you couldn’t tell the difference without a score card. Even compared to H.264 files produced with x264, VP8 holds its own.

The most significant difference between the technologies is the required CPU horsepower to play back the respective files, as shown in Table 1, which contains the results from four different computers. All numbers are “best case,” or the lowest CPU utilization in any of the tested browsers. More on test procedures later.

On a MacBook Pro with GPU acceleration for H.264 decoding, WebM took 38% of the total CPU to play back a 720p file, compared to 24% for H.264 played via Flash and 15% via HTML5 in Apple Safari. On an Acer Aspire One netbook without GPU acceleration for H.264, WebM was actually slightly more efficient than H.264 played back either via Flash or HTML5, though the difference wasn’t significant. Note that the tests on this small-screen netbook involved an 640×480 file, not 720p.

On an HP 8710w mobile workstation with GPU acceleration for H.264 playback, H.264 via Flash required 70% less CPU power than WebM to play back the 720p file, and H.264 via HTML5 took 47% less CPU power. On my daughter’s iMac, WebM and nonaccelerated Flash-based H.264 playback ran neck and neck, while Apple’s Safari, presumably with hardware acceleration, proved 54% more efficient than WebM.

Basically, though, there are huge swings with the individual browsers. Where GPU acceleration exists for H.264, it’s significantly more efficient than WebM; where it doesn’t, the two formats run neck and neck. At this point, between Flash Player 10.1 with hardware acceleration on supported graphics cards and platforms and Apple’s own Safari browser, there are a lot of hardware-accelerated platforms for H.264 playback and few if any for WebM, though they may come in time.

Interestingly, on the WebM website, Google says, “Note: The initial developer preview releases of browsers supporting WebM are not yet fully optimized and therefore have a higher computational footprint for screen rendering than we expect for the general releases. The computational efficiencies of WebM are more accurately measured today using the development tools in the VP8 SDKs. Optimizations of the browser implementations are forthcoming.”

Truth be told, I’m not that much of a geek, so the low-level development tools were a nonstarter for me. However, I did download the DirectShow components to my two Windows computers and played the WebM file via Windows Media Player. On the HP 8710w, CPU load during playback of the same HD WebM file was 18%, with all acceleration disabled, compared to a low of 70% on any of the tested browsers and 21% for hardware-accelerated Flash H.264 playback. On the Acer Aspire One, CPU load dropped to 24%, 30% with hardware acceleration disabled, down from a low of 51% with any of the tested browsers and compared to 53% for nonhardware accelerated Flash-based H.264 playback.

I’m from Missouri (the “Show Me” state) when it comes to all codec-related claims, so I’m not willing to assume that subsequent updates will reduce browser-based WebM playback loads to these levels. If that occurs, however, the value proposition for WebM as compared to H.264 changes to similar quality, a bit slower encode, but much lower playback requirements, which could be pretty compelling, particularly for low-powered mobile markets.

Now that you know the end of the story, let’s dive in at the beginning.

WebM: A Brief History

According to  www.webmproject.org/about , WebM is a “royalty-free, media file format designed for the web.” Briefly, WebM uses the VP8 video codec that Google purchased from On2, the Vorbis audio codec, and a file structure based upon the Matroska container. Though WebM is new, the VP8 codec itself was first launched on Sept. 13, 2008, and comes with some history and some baggage. The history is its predecessor, VP6, which came to prominence when Adobe bundled it into Flash. It is still the most widely used video codec on the internet today. The baggage includes statements in the VP8 press release such as the following:

“With the introduction of On2 VP8, On2 Video now dramatically surpasses the compression performance of all other commercially available formats. For example, leading H.264 implementations require as much as twice the data to deliver the same quality video as On2 VP8 (as measured in objective peak signal to noise ratio [PSNR] testing).”

The press release continues: “In addition, the On2 VP8 bitstream requires fewer processing cycles to decode, so users do not need to have the latest and greatest PC or mobile device to enjoy On2 VP8 video quality.”

During the 11 months that followed the release, On2 never made VP8 available for testing, at least not to me or Streaming Media. And after Google signed the agreement to purchase On2 on Aug. 5, 2009, information about VP8 became tougher to find than President Obama’s fabled Kenyan birth certificate. Google closed the deal on Feb. 19, 2010, and launched WebM on May 19.

Google has never repeated the exact claims that On2 made in the initial press release. But when Google makes claims such as “highest quality real-time video delivery” and “low computational footprint,” it does draw some skepticism. It’s also important to note that VP8 is not a new technology-it’s actually been around for close to 2 years, so it doesn’t get the benefit of the doubt on initial quality or encoding-related issues. That said, you’d have to assume that all browser-related ports began after Google signed the agreement to purchase On2 (August 2009) and perhaps as late as after the deal closed in February, so there certainly could be room for improvement there.

That’s the chatty background. Let’s start looking at test results.

For encoding, I looked at encoding speed and video quality; let’s start with the former. As mentioned, I used a prerelease version of Sorenson Squeeze 6.0.4.63 to produce both the WebM and H.264 files. I produced two test files-one SD, one HD-using long standardized encoding parameters. For the SD file, this meant a target data rate of 500Kbps (468 video/ 32Kbps audio), using two-pass VBR encoding with all quality-related settings set to the max. The Squeeze interface makes this simple, with only a few VP8-related encoding controls, such as trading off size versus complexity and compression quality versus speed ( Figure 1 ).

Figure 1 . Key VP8-related encoding options in the Squeeze interface. Note the Encoding Threads option.

Interestingly, one of the benefits that Google touts about WebM on its website is “Click and encode. Minimal codec profiles, sub-options; when possible, let the encoder make the tough choices.” I was certainly willing to do that and used Sorenson-provided presets for the most part, along with the required adjustments to meet my resolution and data rate targets.

For H.264, I used the High profile, with CABAC enabled, with three B-frames and three-reference frames, and encoding effort set to best. To complete the circle, I configured the HD test files at 720p at a VBR data rate of 800Kbps video/128Kbps audio ( Figure 2 ).

Figure 2. The H.264-related options used in the test comparison.

When producing both WebM and H.264, Squeeze lets you improveencoding speed by using multiple CPUs-WebM via the Encoding Threads option shown in Figure 1, H.264 by using multiple slices (not shown in Figure 2). As you can see in Table 2, I tested using one thread/slice and 12 threads/slices on my HP Z800 with two six-core 3.33GHz Xeon processors, doubled to 24 total cores via hyperthreaded technology (HTT).

With one thread selected, producing the WebM file was very inefficient, with only about 4% of available CPU utilized, and producing the WebM file took almost four times longer than H.264. With 12 threads/slices selected, CPU utilization jumped to as high as 30%, and the differential dropped to less than 25% for the SD file, though WebM still took 85% longer for the HD file. Note that I tried encoding with all 24 threads enabled, and it actually slowed encoding time.

The rap against using multiple threads/slices is that it can degrade quality because the encoder doesn’t search for interframe redundancies between slices, just within each slice. However, I compared the two WebM files and saw minimal, if any, quality differential. Run your own comparison on your content to verify this. But if encoding time is a concern for you, buy a 24-core system like the Z800 and use multiple threads when producing your WebM files. The bottom line is that WebM takes longer to encode, but the differential isn’t that great and probably will only impact high-volume shops.

Quality Trials

When WebM was first announced, I compared a WebM file against an H.264 file produced by Sorenson Squish. I concluded that “H.264 still offers better quality, but the difference wouldn’t be noticeable in most applications.” Now, I’ve spent a bunch of time producing both formats, and I’ve reached the same conclusion.

Note that Sorenson Squeeze uses the MainConcept codec, which has been the highest quality commercially available codec in my comparison tests. To supplement these tests, I also produced comparison files with the x264 codec, using the QuickTime-based x264Encoder version 1.2.13 (dated 6/27/2010) set to the highest quality, slowest encode preset ( Figure 3 ).

Figure 3. Settings used to create the x264 comparison files.

In my tests, x264 produced slightly higher quality than the H.264 files produced by Squeeze with the Main Concept encoder, which was slightly better than WebM ( Figure 4 ). In my view, however, slight differences in quality are irrelevant if the typical viewer wouldn’t notice the difference absent side-by-side comparisons at normal data rates.

Figure 4. Three comparison images produced with x264, WebM and H.264 using the Main Concept codec (click image to see a larger version ).

To explain, I produce my 720p test file at 800Kbps,which means that I’m allocating .029 bits per pixel in the 29.97 frame per second file. In comparison, YouTube produces its 720p H.264 video at about 2Mbps, which means an allocation of .072 bits per pixel, 2.5 times higher than mine. Why are my test files compressed so highly? Because if the data rate is high enough, all technologies look good, and it’s impossible to differentiate.

What’s the most relevant test? In my recent review of video files produced by a range of broadcast and corporate sites, the lowest bits per pixel allocation that I found was 0.43, with most well above .07. Apple produces its iPad advertisements at .168 bits per pixel, about five times higher than my test file, while ESPN produces at .173 and CNN at .106. The notoriously penurious Tiger Woods publishes at .136, though perhaps he’ll tighten this up after losing $750 million in his divorce.

Long story short, if YouTube produces its WebM-based 720p files at 2Mbps at 720p, only the most discriminating viewer will be able to distinguish it from H.264, and then, only with side-by-side comparisons, which, of course, viewers never have. It’s not whether one technology is better than another; it’s whether it’s sufficiently better to make a difference for the typical viewer.

I should point out that some highly respected sources don’t share this opinion. For example, the Graphics and Media Lab of Moscow State University produces a codec comparison every year;  this year it included VP8 . In terms of H.264 encoding quality, the report concludes that “[t]he x264 encoder demonstrates better quality on average, and MainConcept shows slightly lower quality,” which was my primary motivation for including x264 in this evaluation. Regarding VP8, the report concludes, “When comparing VP8 and x264 VP8 also shows 5-25 lower encoding speed with 20-30% lower quality at average.” I just didn’t see that.

Then there’s x264 developer  Jason Garrett-Glaser’s extensive analysis  of VP8 and comparison to x264, which concludes that x264 is 28% better than VP8, though his comparisons seem to focus on 1080p delivery, so it’s unclear how much you can generalize these results to streaming. In any event, Garrett-Glaser’s analysis is wonderful reading for anyone who wants to understand the inner workings of the VP8 codec and WebM spec, as well as the patent issues that WebM may be facing.

Both these comparisons rely primarily on automated quality measurements such as Peak Signal to Noise ratio (PSNR) and Structured Similarly (SSIM), which compare the encoded frame to the original and produce a comparative numerical score. I produce the files with the different technologies, making sure that they’re within 5% of the target data rate without dropped frames. I then grab frames for comparison purposes and watch the files side by side to assess the presence of motion artifacts. You can view my HD comparisons at  www.doceo.com/HD_Comps.html  and my SD comparisons at  www.doceo.com/SD_Comps.html , and comparative frame grabs are at  www.streaminglearningcenter.com . Draw your own conclusions.

Overall, I’m sure that Garrett-Glaser can coax more quality out of x264 than I can. But find comfort in the fact that the Moscow study concluded that MainConcept “shows slightly lower quality” than x264, which is consistent with my results. Certainly, if you’re using a MainConcept-based tool such as Squeeze, the quality difference between VP8 and H.264 will be meaningless at most relevant data rates.

Playback Requirements

Which takes us neatly back to playback requirements, which is where we started. Let’s introduce the computers and browsers.

Briefly, I tested on four computers. The MacBook Pro has a 3.06GHz Core 2 Duo CPU, 8GB RAM, and was running OS 10.6.2 with an NVIDIA GeForce 9600M graphic chip. The iMac has a 2.0GHz Core 2 Duo CPU, 2.5GB of RAM, and an ATI Radeon X1600 graphics chip while running OS 10.6.

The HP 8710w was running a 64-bit version of Windows 7 on a 2.2GHz Intel Core 2 Duo CPU with 2GB of RAM and an NVIDIA Quadro FX 1600M graphics controller. The Acer Aspire One is a netbook running Windows XP Home Edition with a 1.60GHz Intel Atom CPU, 1GB of RAM, and an integrated Intel 945 Express Chipset for graphics. All computers except the Aspire netbook were measured playing back the 720p file, and Table 3 shows the browsers used in the respective tests.

During testing, I followed this procedure: • I turned off as many background processes as possible.  • I updated my graphics card drivers.  • First, I loaded the page and waited until the video completely downloaded (watching the little bar thingie on the bottom of the player).  • Next, I played the file, monitoring and recording the CPU usage on Windows Task Manager and percentage idle on the Activity Monitor. Obviously, to compute CPU utilization for the Macs, I subtracted the percentage idle from 100%.

Table 4 shows the results grouped by format and playback environment. Pulling some conclusions out of these disparate numbers is challenging, but here goes. Most obvious is the fractured nature of the HTML5 market, which still lacks a single codec that can play across all platforms. With Microsoft only supporting VP8 playback on IE 9 if the codec is otherwise installed, and Apple squarely in the H.264 camp, Google’s open sourcing of VP8 has done nothing to reduce this logjam. As you have probably heard, Adobe has announced that a future version of the Flash Player will support WebM at some point; that may end up being the only easy way to display WebM video across all relevant browsers. However, one suspects that you could buy a Tastee Freez in Hades before WebM will play on the walled garden of Apple iDevices.

If you’re a Mac owner who consumes lots of video, you can see that results vary by browser and if your Flash implementation is hardware accelerated. If it is, Safari is your best option; if not, go with Chrome. As a random thought, people watching Flash-video on a nonaccelerated Mac via Opera or Safari probably consider Flash a CPU hog-I wonder if their opinions would change if they did switch to Chrome. Ditto for HTML5-based H.264 playback on the Mac, where Safari is the efficiency king and Chrome the laggard.

Regarding WebM, on the platforms without Flash GPU acceleration (the iMac and Aspire), the most efficient WebM implementation required less CPU than the most efficient Flash implementation, though the WebM implementations varied more widely. Absent hardware acceleration, CPU utilization on playback appears to be a wash.

As I mentioned at the beginning of this article, when playing a WebM 720p file on the HP 8710w via Media Player, CPU requirements dropped to 18%, about a third of the requirement of the most efficient browser and within spitting distance of GPU-accelerated Flash playback. On the Aspire for the 640×480 file, CPU load dropped to 24%; 30% with hardware acceleration disabled, which is much lower than any other tested technology. If any of the browser vendors can enable this level of efficiency for web-based playback, WebM would have a significant competitive advantage over H.264, whether Flash- or HTML5-based. If not, given that many newer computers and mobile devices offer some measure of Flash acceleration, WebM may trail in quality, encoding speed, and playback efficiency.

As it stands today, WebM’s value proposition is basically that it’s free and better than Ogg Theora; though it’s way too tough to decode as compared to the rapidly expanding base of GPU-accelerated H.264. If the browser vendors and Google can reduce CPU playback requirements to levels shown in Media Player, however, the story changes considerably, at least for pay-per-view and subscription-based video distributors, who currently pay a fee to deliver H.264 video. Ironically, given the lack of universal HTML5 browser support, the most efficient way to distribute WebM to your customers may be via the Flash Player, assuming that the Flash Player’s CPU playback requirements are competitive. You’ll probably still have to write checks to MPEG-LA for delivering to Apple’s iDevices, however.

As you probably know, H.264 is royalty-free for free internet distribution, at least through 2015, so there’s no financial incentive to switch. If your organization wants to migrate toward HTML5, WebM doesn’t provide that single codec solution, is still lower quality than H.264 (however small the difference), and takes longer to encode. Overall, for those not charging for their video, H.264 is still a better solution, and given the rapidly increasing size of the GPU-accelerated installed base, it will likely remain so, unless and until Google creates distribution channels that you can’t access with H.264.

Tags Choosing a codec H.264 production

What is MV-HEVC

Multiview High Efficiency Video Coding (MV-HEVC) is an advanced video compression standard that extends the …

Deep Thoughts on AI Codecs and Encoders

This post focuses on AI in preprocessing and encoding products. I’ll examine two aspects: how …

Beyond the Hype: A Critical Look at AI in Video Streaming

I recently presented at Dan Rayburn’s Streaming Summit at NAB 2024. The topic was Beyond …

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

WebKit in Safari 18 beta">News from WWDC24: WebKit in Safari 18 beta

Jun 10, 2024

by Jen Simmons, Jon Davis, Karl Dubost, Anne van Kesteren, Marcos Cáceres, Ada Rose Canon, Tim Nguyen, Sanjana Aithal, Pascoe, and Garrett Davidson

Web apps for Mac

Safari extensions, spatial media, web inspector, deprecations, bug fixes and more, help us beta test.

The last year has been a great one for WebKit. After unveiling Safari 17 beta at WWDC23, we’ve shipped six releases of Safari 17.x with a total of 200 new web technologies. And we’ve been hard at work on multiple architectural improvement projects that strengthen WebKit for the long-term.

Now, we are pleased to announce WebKit for Safari 18 beta. It adds another 48 web platform features, as well as 18 deprecations and 174 bug fixes. Test it today on iOS 18 beta, iPadOS 18 beta, visionOS 2 beta, and macOS Sequoia beta.

Safari 18 for visionOS 2 beta adds support for WebXR . Now you can create fully immersive experiences and deliver them on the web to people using Apple Vision Pro . Safari on visionOS 2 beta supports immersive-vr sessions. WebXR scenes are displayed using hardware-accelerated graphics driven by WebGL .

Safari for visionOS 2 beta supports the new WebXR transient-pointer input mode. It lets you make the most of natural input on visionOS, and allow your users to interact with a look and a pinch.

If you want to animate a 3D model of the user’s hands, Safari for visionOS 2 beta also includes support for WebXR hand tracking . To ensure privacy, permission to allow hand tracking will be requested from users at the start of their WebXR session.

Learn all about WebXR on visionOS 2 beta by watching Build immersive web experiences with WebXR at WWDC24, available Wednesday June 12. And learn more about transient-pointer input mode by reading Introducing natural input for WebXR in Apple Vision Pro .

View Transitions

WebKit added support for the View Transitions API in Safari 18 beta. It provides an optimized browser API to animate elements from one state to another. Safari supports the CSS View Transitions Module Level 1 specification that adds new CSS properties and pseudo-elements for defining transition animations, along with a new browser API to start transition animations and react to different transition states. It works by capturing the current (old) state of the page and applying an animated transition to the new state. By default, the browser applies a cross-fade between the states.

Call the document.startViewTransition() method to initiate the capture. You can pass a callback function as the first argument to make DOM state changes between the old and new captures. The method returns a ViewTransition object which contains promises that can be used to track when the view transition starts or ends.

Once the states are captured, a pseudo-element tree is built which can be targeted with CSS, allowing you to modify the CSS animations used for the transitions. The animations out of the old page state and into the new page state can be modified via the ::view-transition-new(*) and ::view-transition-old(*) selectors. You can also ask the browser to independently track state changes for a specific element by naming it with the CSS view-transition-name property. You can then use the pseudo-element to customize animations for it.

The example below demonstrates state management with tabbed navigation. Each tab view has a custom transition animation out and a subtly different animation in, while the tabs themselves rely on the default page transition.

Style Queries

WebKit for Safari 18 beta adds support for Style Queries when testing CSS Custom Properties. Similar to how developers can use Sass mixins, Style Queries can be used to define a set of reusable styles that get applied as a group.

Here, if the --background custom property is set to black, then certain styles will be applied — in this case to make the headline and paragraph text color white.

Don’t forget to pay attention the HTML structure. By default, Style Queries reference the styles on the direct parent element. You can create a different reference through the use of Container Query names.

currentcolor and system color keywords in Relative Color Syntax

Support for Relative Color Syntax shipped in Safari 16.4 . It lets you define colors in a more dynamic fashion, creating a new color from an existing color. The value lch(from var(--color) calc(L / 2) C H) for instance uses the lch color space to take the variable --color and calculate a new color that’s half its lightness, calc(L / 2) .

Now, starting in WebKit for Safari 18 beta, you can reference the currentcolor or a system color keyword as you define the new color. For example, this code will set the background color to be the same color as the text color, only 4 times lighter, as calculated in the oklch color space.

Being able to reference system color keywords opens up another world of options. System colors are like variables that represent the default colors established by the OS, browser, or user — defaults that change depending on whether the system is set to light mode, dark mode, high contrast mode, etc. For example, canvas represents the current default background color of the HTML page, while fieldtext matches the color of text inside form fields. Find the full list of system colors in CSS Color level 4 .

Relative Color Syntax lets you define dynamic connections between colors in your CSS, lessening the need to control color through variables in a tightly-regimented design system. Learn more about Relative Color Syntax by watching this portion of What’s new in CSS from WWDC23.

Animating display

WebKit for Safari 18 beta adds support for transition animation of the display property.

Many developers are excited to use @starting-style along with transition-behavior and display: none interpolation. WebKit for Safari 17.4 added general support for transition-behavior , including transition-behavior: allow-discrete . WebKit for Safari 17.5 added support for @starting-style , letting you define starting values for transitioning an element as it’s created (or re-created). Now in WebKit for Safari 18 beta, you can use these features together to transition the display property.

Shaping interaction regions on visionOS

As a web developer, you’re very familiar with how link styling works on the web. For decades you’ve been able to use CSS to style text-decoration , color and more for :link , :hover , :active , and :visited states. You’ve also been able to adjust the size of the invisible tap target through use of padding.

Apple Vision Pro adds a new dimension to how links work — tap targets are visible on visionOS. Anytime a user looks at an interactive element, it’s highlighted to let them know that it can be tapped. And you as a designer or developer can intentionally design how an interaction region looks. You may want to add padding, for instance, or even a rounded corner to the otherwise invisible box.

Now in Safari in visionOS 2 beta, when you use CSS clip-path to change the shape of tappable area of a link, the visible interaction region will change shape as well. Interactive UI elements built with SVG will also be highlighted with the proper shape. Learn more by watching Optimize for the spatial web at WWDC24, available Tuesday June 11.

Backdrop Filter

Originally shipped in Safari 9.0, backdrop filter provides a way to apply graphics effects to the content behind a particular element. You can apply backdrop-filter to a headline, for example, and everything behind the headline will be blurred, or have decreased saturation, or increased contrast. Any of the filter functions from SVG can be used — blur() , brightness() , contrast() , drop-shadow() , grayscale() , hue-rotate() , invert() , opacity() , saturate() , and sepia() .

For many years, backdrop filter only worked in Safari. It was available when you prefixed the property with -webkit-backdrop-filter . Now, starting in Safari 18 beta, you don’t need the prefix. We also improved our implementation, fixing bugs and boosting interoperability.

This demo shows eight different filters and what you might do with each one alone. You can, of course, combine filters to create even more interesting results. With backdrop filter supported in Safari since 2015, Edge since 2018, Chrome since 2019, Samsung Internet since 2020, and Firefox since 2022, this is a great time to consider the kind of graphic design possibilities it enables.

safe in Flexbox

WebKit for Safari 18 beta adds support for the safe keyword for alignment in Flexbox. This provides a mechanism for refining how flex items overflow. Let’s look at an example of a simple navigation menu — a classic use of Flexbox.

The following CSS creates a simple layout that wraps when there’s not enough space on one line for the menu, while centering the items in the available space.

By default, justify-content: center will always keep the items centered, even when the content is overflowing the containing box. You might prefer, however, that the content not be centered when it overflows — being centered cuts off both the beginning and end of the word, making the content harder to understand when the overflow is not visible.

The safe keyword lets you change how alignment works when content overflows. The justify-content: safe center rule will instead start align any item that is overflowing, while continuing to center the items that are not overflowing.

If you want to override the safe keyword, you can use unsafe . The justify-content: unsafe center rule will do the same thing as justify-content: center . The unsafe keyword has been supported in WebKit for Safari for quite some time.

Content visibility

WebKit for Safari 18 beta adds support for content-visibility . This property controls whether or not an element renders its contents in a fashion that’s useful for making performance optimizations. It lets you communicate to the browser that certain portions of the page will likely be initially offscreen, and suggest they be omitted from layout and rendering. This can make the page load faster.

Last year , we added support for web apps in macOS Sonoma. You can add any website to your dock — whether or not it was built with a Manifest file, Service Worker, or other technology to customize the web app experience. Go to the site in Safari, then File > Add to Dock… where you can customize the icon, change the name, and even clean up the URL. Then, just click on the web app icon in your Dock, and it will open as an app.

This year brings two improvements to web apps on Mac.

Opening links

macOS Sequoia beta adds support for opening links directly in web apps. Now, when a user clicks a link, if it matches the scope of a web app that the user has added to their Dock, that link will open in the web app instead of their default web browser.

For example, imagine you have added MDN Web Docs to the Dock. Then a colleague sends you a link to an MDN page in Messages, Mail, Slack, Discord, IRC, or any non-browser application on your Mac. Now when you click on that link, it will open in the MDN Web Docs web app instead of your default browser.

Clicking a link within a browser will maintain the current behavior. This feature only affects links opened elsewhere. (When a user is in Safari, clicking on a link that matches the scope of a web app that is added to Dock, they will see an “Open in web app” banner, unless they have previously dismissed the banner.)

By default, this behavior applies when the link matches the host of the web page used to create the web app. As a developer, you can refine this experience by defining the range of URLs that should open in the web app with the scope member in the web app manifest .

Extension support

Now you can personalize web apps on Mac with Safari Web Extensions and Content Blockers. Navigate to the web app’s Settings menu to access all your installed Content Blockers and Web Extensions. Any enabled in Safari will be on by default in the web app. Each web app is uniquely customizable, just like Safari profiles.

Safari 18 beta also adds support for Mobile Device Management of extension enabled state, private browsing state, and website access on managed devices. This means schools and businesses that manage iOS, iPadOS, or macOS devices can now include the configuration of Safari App Extensions, Content Blockers, and Web Extensions in their management.

One of the amazing experiences you can have on Apple Vision Pro is looking at spatial photos and panoramas. When you open the Photos app in visionOS, you see a montage of your photos. Tap an image, it appears alone in a floating frame in front of you, while the rest of the app disappears.

A spatial photo appears at just the right height and viewing angle to make it feel like you’ve gone back to a moment in time. A second tap of the UI breaks it out of the frame, as it grows and becomes even more immersive. Similarly, a panorama floats in a frame on first tap. Then on second tap of the UI, it expands to wrap all around you, creating a fully immersive experience.

Now in Safari 18 for visionOS 2 beta, you can use the Fullscreen API to create the same experience on the web. You can embed the photo in a web page, and provide the ability to tap. The photo will pop into a floating frame as the Safari window disappears. Then when the user taps on the spatial photo or panorama UI that visionOS provides, the photo will further expand to create a fully immersive experience. When they exit the image, the Safari window will return.

Let’s walk through how to support experiencing a spatial photo or panorama on the web using Fullscreen API. First, include the image on your web page using any of the techniques we’ve used on the web for years. Here, we can embed a flattened panoramic photo into the web page using simple HTML.

Then using JavaScript, we’ll trigger .requestFullscreen() on tap. Perhaps like this.

You could, of course, create your own UI for the user to tap, rather than making the entire photo the tap target.

Spatial images work just the same, although it’s likely we want to provide fallbacks for browsers that do not support HEIC files . We can do so with the picture element.

Spatial images are stereoscopic, with both a left and right channel. In Safari, when the image is embedded in the web page, the browser will show the left channel. And there’s no need to worry about providing a fallback of any sort for Safari on macOS, iOS, or iPadOS — the stereoscopic HEIC file works great.

This technique will also cause images to go fullscreen in any browser that supports Fullscreen API. Learn more about adding panorama and spatial photos to your websites by watching Optimize for the spatial web at WWDC24, available Tuesday June 11.

Writing Suggestions

At last year’s WWDC, Apple unveiled inline predictive text on iOS, iPadOS, macOS and more. It helps users input text faster by predicting what they might be typing and finishing the word, phrase or even a whole sentence when the user taps the space bar. Now, WebKit for Safari 18 beta on iOS, iPadOS, visionOS, macOS Sequoia and macOS Sonoma brings inline predictive text to the web.

While inline predictive text makes for a fantastic, personalized user experience, there might be specific situations on the web where it’s better to not have predictions. WebKit for Safari 18 beta on iOS, iPadOS, visionOS, macOS Sequoia and macOS Sonoma gives web developers the opportunity to disable inline predictions through the writingsuggestions attribute. By default, writing suggestions is set to true. You can turn off the capability by including the writingsuggestions="false" attribute on any type of text input field.

WebKit for Safari on iOS 18 beta adds haptic feedback for <input type=checkbox switch> . This means, now when a user taps a switch control on iPhone, a single tap is felt — just like how toggling a switch feels in Settings app on iOS. Try this demo to see what it’s like.

Date and time inputs

WebKit for Safari 18 beta on macOS improves accessibility support for date and time input field types. Now <input type="date"> , <input type="datetime-local"> , and <input type="time"> elements work properly with VoiceOver.

Usually elements have the labels they need, but sometimes there is no text label for a particular button or UI. In this situation, ARIA can be used to provide an accessible label. The aria-label attribute provides names of labels while aria-roledescription provides the description for the role of an element.

On very rare occasions, you may need to override aria-label or aria-roledescription to provide different names or descriptions specifically for braille. The aria-braillelabel and aria-brailleroledescription attributes provide such an ability. They exist to solve very specific needs, including educational contexts where the site needs to render the specific braille table dot pattern. If you do use braille-related ARIA attributes, be sure to test them using a braille reader. If in doubt, relying on the accessible name from content or aria-label / aria-roledescription is almost always the better user experience . WebKit has supported these ARIA attributes for years.

Now, WebKit for Safari 18 beta adds support for the ariaBrailleLabel and ariaBrailleRoleDescription element reflection properties. These make it possible to get and set the aria-braillelabel and aria-brailleroledescription ARIA attributes on DOM elements directly via JavaScript APIs, rather than by using setAttribute and getAttribute .

Watch video without distractions in Viewer for Safari 18 beta on macOS.

When you play in Viewer, the video fills the Safari window, while providing full access to system playback controls. Then it automatically enters picture-in-picture anytime you switch tabs, close the window, or occlude the web page with another window. Look for Video Viewer in the new page menu in Safari whenever you are on a web page with a prominent video element.

Video on visionOS

Managed Media Source

WebKit for Safari 18 beta adds Workers support for both Managed Media Source (MMS) and Media Source Extensions ( MSE ). This can be especially helpful on complex websites that want to ensure continuous and smooth video playback even when other site activity (such as live commenting) causes a very busy main thread. You can see the performance difference in this demo .

WebKit for Safari 18 beta adds support for the WebRTC HEVC RFC 7789 RTP Payload Format. Previously, the WebRTC HEVC used generic packetization instead of RFC 7789 packetization. This payload format provides a new option for improving videoconferencing, video streaming, and delivering high-bitrate movies and TV shows.

WebKit for Safari 18 beta adds support for MediaStreamTrack processing in a dedicated worker. And it adds support for missing WebRTC stats.

Two years ago at WWDC22, we announced support for passkeys — a groundbreaking industry-standard way to login to websites and app services. Passkeys provide people with an extremely easy user experience, while delivering a profound increase in security. To learn more, watch Meet Passkeys or read Supporting passkeys .

WebKit for Safari 18 beta adds support for three new features as we continue to improve passkeys. First, Safari 18 beta adds support for using mediation=conditional for web authentication credential creation. This allows websites to automatically upgrade existing password-based accounts to use passkeys. Learn more by watching Streamline sign-in with passkey upgrades and credential managers at WWDC24, available on Tuesday, June 11.

Second, WebKit for Safari 18 beta adds support for using passkeys across related origins. This lets websites use the same passkey across a limited number of domains which share a credential backend.

And third, WebKit for Safari 18 beta adds support for the WebAuthn prf extension. It allows for retrieving a symmetric key from a passkey to use for the encryption of user data.

WebKit for Safari 18 beta adds support for secure HTTPS for all images, video, and audio by upgrading passive subresource requests in mixed content settings. This means that if some files for a website are served using HTTPS and some are served using HTTP (known as “mixed content”), all images and media will now be auto-upgraded to HTTPS, in adherence with Mixed Content Level 2 .

WebKit for Safari 18 beta adds support for Unicode 15.1.0 characters in RegExp. Unicode 15.1 added 627 characters, bringing the total of characters to 149,813. Now, these new characters can be used in regular expressions.

WebKit for Safari 18 beta also adds support for the v flag with RegExp.prototype[Symbol.matchAll] . providing more powerful ways to match Unicode characters, as specified in the ECMAScript 2024 standard.

For example, you can now specify to only match on Latin characters, while avoiding matching on Cyrillic script characters.

Or split a string matching on Emojis.

WebKit for Safari 18 beta adds support for URL.parse() , a way to parse URLs which returns null rather than an exception when parsing fails.

WebKit for Safari 18 beta expands Declarative Shadow tree support by adding the shadowRootDelegatesFocus and shadowRootClonable IDL attributes to the <template> element. It also adds the shadowRootSerializable attribute and shadowRootSerializable IDL attribute to the <template> element, enabling those using Declarative Shadow roots to opt into making them serializable. Serializing can be done through the new getHTML() method that has been added at the same time.

WebKit for Safari 18 beta adds support for PopStateEvent ’s hasUAVisualTransition , indicating whether the user agent has a visual transition in place for the fragment navigation.

WebKit for Safari 18 beta adds support for subresource integrity in imported module scripts, which gives cryptographic assurances about the integrity of contents of externally-hosted module scripts.

WebKit for Safari 18 beta adds support for the bytes() method to the Request, Response , Blob , and PushMessageData objects. This replaces the need for web developers to call arrayBuffer() , which can be difficult to use, and wraps the result in a Uint8Array . Calling bytes() is now the recommended way going forward when you need to access the underlying bytes of the data these objects represent.

WebKit for Safari 18 beta adds support for feature detecting text fragments by exposing document.fragmentDirective . Note that the returned object (a FragmentDirective ) doesn’t provide any functionality, but it’s helpful if you need to know if Fragment Directives are supported by the browser.

WebKit for Safari 18 beta adds support for the willReadFrequently context attribute for the getContext() method. It indicates whether or not a lot of read-back operations are planned. It forces the use of a software accelerated 2D or offscreen canvas, instead of hardware accelerated. This can improve performance when calling getImageData() frequently.

WebKit for Safari 18 beta extends 2D canvas support for currentcolor . It can now be used inside color-mix() or Relative Color Syntax. Here currentcolor will default to the computed color property value on the canvas element.

WebKit for Safari 18 beta adds support for six new WebGL extensions:

• EXT_texture_mirror_clamp_to_edge
• WEBGL_render_shared_exponent
• WEBGL_stencil_texturing
• EXT_render_snorm
• OES_sample_variables
• OES_shader_multisample_interpolation

WebKit for Safari 18 beta adds support for fuzzy search code completion in the Web Inspector’s CSS source editor.

WebKit for iOS 18 beta, iPadOS 18 beta, visionOS 2 beta, and macOS Sequoia beta adds support for two new API — the Writing Tools API and an API to control adaptive image glyph insertion. Learn more about these API by watching Get started with Writing Tools and Bring expression to your app with Genmoji at WWDC24, both available Tuesday June 11.

WebKit for Safari 18 beta adds support for Apple Pay funds transfer.

While it’s rare to deprecate older technology from the web, there are occasions when it makes sense. We’ve been busy removing -webkit prefixed properties that were never standardized, aging media formats that were never supported in other browsers, and more. This helps align browser engines, improve interoperability, and prevent compatibility problems by reducing the possibility that a website depends on something that’s not a web standard.

WebKit for Safari 18 beta removes support for OffscreenCanvasRenderingContext2D ’s commit() method.

WebKit for Safari 18 beta deprecates support for a number of rarely used -webkit prefixed CSS pseudo-classes and properties — and even one -khtml prefixed property.

• -webkit-alt and alt properties
• :-webkit-animating-full-screen-transition pseudo-class
• :-webkit-full-screen-ancestor pseudo-class
• :-webkit-full-screen-controls-hidden pseudo-class
• :-webkit-full-page-media pseudo-class
• :-webkit-full-screen-document pseudo-class
• :-khtml-drag pseudo-class

WebKit for Safari 18 beta also deprecates support for the resize: auto rule. Support for the resize property remains, just as it’s been since Safari 4. The values Safari continues to support include : none , both , horizontal , vertical , block , inline , plus the global values. Early versions of CSS Basic User Interface Module Level 3 defined auto , but it was later written out of the web standard.

WebKit for Safari 18 beta also deprecates support for non-standardize WEBKIT_KEYFRAMES_RULE and WEBKIT_KEYFRAME_RULE API in CSSRule .

WebKit for Safari 18 beta removes support for the JPEG2000 image format. Safari was the only browser to ever provide support.

If you’ve been serving JPEG2000 files using best practices, then your site is using the picture element to offer multiple file format options to every browser. Safari 18 beta will simply no longer choose JPEG2000, and instead use a file compressed in JPEG XL, AVIF, WebP, HEIC, JPG/JPEG, PNG, or Gif — choosing the file that’s best for each user. Only one image will be downloaded when you use <picture> , and the browser does all the heavy lifting.

We have noticed that some Content Deliver Networks (CDN) use User Agent sniffing to provide one file to each UA, offering only JPEG2000 images to Safari — especially on iPhone and iPad. If you expect this might be happening with your site, we recommend testing in Safari 18 beta on both macOS Sequoia and iOS or iPadOS 18. If you see problems, contact your SaaS provider or change your image delivery settings to ensure your website provides fallback images using industry best practices.

If you notice a broken site, please file an issue at webcompat.com .

WebKit for Safari 18 beta removes support for non-standard VTTRegion.prototype.track .

WebKit for Safari 18 beta removes the last bits of support for AppCache.

When AppCache first appeared in 2009, in Safari 4, it held a lot of promise as a tool for caching web pages for use offline. It was imagined as “HTML5 Application Cache” back when HTML itself was being further expanded to handle more use cases for web applications. A developer could create a simple cache manifest file with a list of files to be cached. Its simplicity looked elegant, but there was no mechanism for cache busting, and that made both developing a site and evolving the site over time quite frustrating. AppCache also had security challenges. So new web standards were created to replace it. Today, developers use Service Workers and Cache Storage instead.

WebKit deprecated AppCache with a warning to the Console in Safari 11.0. Then in 2021, we removed support for AppCache from Safari 15.0, with a few exceptions for third-party users of WKWebView . Now we are removing those exceptions. This change to WebKit will only affect the rare web content loaded in older third-party apps that have JavaScript code which relies on the existence of AppCache related interfaces.

WebKit for Safari 18 beta removes the SVGAnimateColorElement interface.

WebKit for Safari 18 beta removes support for four non-standard Web APIs:

• KeyboardEvent.altGraphKey
• AES-CFB support from WebCrypto
• KeyboardEvent.prototype.keyLocation
• HashChangeEvent ’s non-standard initHashChangeEvent() method

In addition to all the new features, WebKit for Safari 18 beta includes work to polish existing features.

Accessibility

• Fixed role assignment for <header> inside <main> and sectioning elements.
• Fixed range input not firing an input event when incremented or decremented via accessibility APIs.
• Fixed setting aria-hidden on a slot not hiding the slot’s assigned nodes.
• Fixed comboboxes to expose their linked objects correctly.
• Fixed time input accessibility by adding labels to subfields.
• Fixed aria-hidden=true to be ignored on the <body> and <html> elements.
• Fixed datetime values being exposed to assistive technologies in the wrong timezone.
• Fixed time control accessibility by adding a label to the meridiem component.
• Fixed wrong datetime value being exposed to assistive technologies for datetime-local inputs.
• Fixed ignored CSS content property replacement text when it is an empty string.
• Fixed the computed role for these elements: dd , details , dt , em , hgroup , option , s , and strong .
• Fixed hidden elements targeted by aria-labelledby to expose their entire subtree text, not just their direct child text.
• Fixed accessible name computation for elements with visibility: visible inside a container with visibility: hidden .
• Fixed updating table accessibility text when its caption dynamically changes.
• Fixed updating aria-describedby text after the targeted element changes its subtree.
• Fixed the transition property to produce the shortest serialization.
• Fixed the animation property to produce the shortest serialization.

Authentication

• Fixed navigator.credentials.create() rejects with “NotAllowedError: Operation Failed” after a conditional UI request is aborted.
• Fixed renaming DigitalCredential’s response attribute to data .
• Fixed setting the cancel flag once the cancel completes regardless of a subsequent request occurring.
• Fixed drawImage(detachedOffscreenCanvas) to throw an exception.
• Fixed OffscreenCanvas failing to render to the placeholder with nested workers.
• Fixed losing the contents layer of the placeholder canvas of OffscreenCanvas when switching off the tab.
• Fixed drawImage to not alter the input source or the destination rectangles.
• Fixed toggling the visibility on a canvas parent undoing the effect of clearRect() .
• Fixed the Canvas drawImage() API to throw an exception when the image is in broken state.
• Fixed setting white-space to a non-default value dynamically on a whitespace or a new line.
• Fixed turning text-spacing properties into font properties.
• Fixed custom counter styles extending disclosure-open and disclosure-closed to point to the correct direction in right-to-left.
• Fixed backface-visibility to create a stacking context and containing block.
• Fixed getComputedStyle() to work with functional pseudo-elements like ::highlight() .
• Fixed: Aliased :-webkit-full-screen pseudo-class to :fullscreen .
• Fixed: Aliased :-webkit-any-link to :any-link and :matches() to :is() .
• Fixed getComputedStyle() pseudo-element parsing to support the full range of CSS syntax.
• Fixed @supports to correctly handle support for some -webkit prefixed pseudo-elements that were incorrectly treated as unsupported.
• Fixed updating media-query sensitive meta tags after style changes.
• Fixed changing color scheme to update gradients with system colors or light-dark() .
• Fixed incorrect inline element size when using font-variant-caps: all-small-caps with font-synthesis .
• Fixed :empty selector to work with animations.
• Fixed preserving whitespace when serializing custom properties.
• Fixed updating style correctly for non-inherited custom property mutations.
• Fixed element removed by parent to end up losing the last remembered size.
• Fixed an incorrect difference between implicit and explicit initial values for custom properties.
• Fixed the contrast of Menu and MenuText system colors.
• Fixed keeping the shorthand value for CSS gap as-is in serialized and computed values.
• Fixed the style adjuster for @starting-style incorrectly invoking with a null element.
• Fixed excluding -apple-pay-button from applying to any element that supports appearance: auto and is not a button.
• Fixed missing color interpretation methods added to CSS color specifications.
• Fixed hsl() and hsla() implementation to match the latest spec changes.
• Fixed the implementation of rgb() and rgba() to match the latest spec.
• Fixed the hwb() implementation to match the latest spec.
• Fixed the remaining color types to be synced with the latest spec changes.
• Fixed carrying analogous components forward when interpolating colors
• Fixed applying the fill layer pattern for mask-mode .
• Fixed displayed datalist dropdown to sync its options elements after a DOM update.
• Fixed <select multiple> scrollbars to match the used color scheme.
• Fixed updating the input value when selecting an <option> from a <datalist> element.
• Fixed the value attribute not getting displayed in an input element with type="email" and the multiple attribute.
• Fixed the iOS animation for <input type=checkbox switch> .
• Fixed form controls drawing with an active appearance when the window is inactive.
• Fixed constructed FormData object to not include entries for the image button submitter by default.
• Fixed the properties of History to throw a SecurityError when not in a fully active Document.
• Fixed “about:blank” document.referrer initialization.
• Fixed parsing a self-closing SVG script element. It now successfully executes.
• Fixed RegExp.prototype.@@split to update the following legacy RegExp static properties: RegExp.input , RegExp.lastMatch , RegExp.lastParen , RegExp.leftContext , RegExp.rightContext , and RegExp.$1, ... RegExp.$9 .
• Fixed String.prototype.replace to not take the fast path if the pattern is RegExp Object and the lastIndex is not numeric. (
• Fixed spec compliance for Async / Await, Generators, Async Functions, and Async Generators.
• Fixed async functions and generators to properly handle promises with throwing “constructor” getter.
• Fixed return in async generators to correctly await its value.
• Fixed Symbol.species getters to not share a single JS Function.
• Fixed throwing a RangeError if Set methods are called on an object with negative size property.
• Fixed eval() function from another realm to not cause a direct eval call.
• Fixed eval() call with ...spread syntaxt to be a direct call.
• Fixed try/catch to not intercept errors originated in [[Construct]] of derived class.
• direct eval() in a default value expression inside a rest parameter creates a variable in the environment of the function rather than the separate one of the parameters;
• a ReferenceError is thrown when accessing a binding, which is defined inside rest parameter, in eval() , or a closure created in a default value expression of a preceding parameter, but only if there is a var binding by the same name;
• a closure, created in the default value expression inside a rest parameter, is created in a different VariableEnvironment of the function than its counterparts in preceding parameters which causes the incorrect environment to be consulted when querying or modifying parameter names that are “shadowed” by var bindings.
• Fixed TypedArray sorting methods to have a special-case for camparator returning false .
• Fixed programming style for bitwise and in setExpectionPorts.
• Fixed emitReturn() to load this value from arrow function lexical environment prior to the TDZ check.
• Fixed NFKC normalization to work with Latin-1 characters.
• Fixed parsing of private names with Unicode start characters.
• Fixed instanceof to not get RHS prototype when LHS is primitive.
• Fixed bracket update expression to resolve property key at most once.
• Fixed bracket compound assignement to resolve the property key at most once.
• Fixed Object.groupBy and Map.groupBy to work for non-objects.
• Fixed Array.fromAsync to not call the Array constructor twice.
• Fixed inconsistent output of Function.prototype.toString for accessor properties.
• Fixed Set#symmetricDifference to call this.has in each iteration.
• Fixed logical assignment expressions to throw a syntax error when the left side of the assignment is a function call.
• Fixed throwing a syntax error for nested duplicate-named capturing groups in RegEx.
• Fixed ArrayBuffer and SharedArrayBuffer constructor to check length before creating an instance.
• Fixed Intl implementation to ensure canonicalizing “GMT” to “UTC” based on a spec update.
• Fixed RegEx lookbehinds differing from v8.
• Fixed fractionalDigits of Intl.DurationFormat to be treated as at most 9 digits if it is omitted.
• Fixed navigator.cookieEnabled to return false when cookies are blocked.
• Fixed video sound coming from another window after changing tabs in the Tab Bar in visionOS.
• Fixed playback for MSE videos on some sites.
• Fixed allowing a video’s currentTime to be further than the gap’s start time.
• Fixed broken audio playback for a WebM file with a Vorbis track.
• Fixed sampleRate and numberOfChanges to be required and non-zero in a valid AudioEncoderConfig.
• Fixed media elements appending the same media segment twice.
• Fixedrejecting valid NPT strings if ‘hours’ is defined using 1 digit.
• Fixed an issue where Safari audio may be emitted from the wrong window in visionOS.
• Fixed upgrading inactive or passive subresource requests and fetches in would-be mixed security contexts to match standards.
• Fixed incorrect Sec-Fetch-Site value for navigation of a nested document.
• Fixed loading WebArchives with a non-persistent datastore.
• Fixed Timing-Allow-Origin to not apply to an HTTP 302 response.
• Fixed print buttons with a print action implementation.
• Fixed Open in Preview for a PDF with a space in its name.
• Fixed Greek uppercase transforms failing for some characters.
• Fixed resizing a <textarea> element with 1rem padding.
• Fixed the color correctness of the color matrix filter.
• Fixed backdrop-filter to apply to the border area of an element with a border-radius .
• Fixed intrinsic inline size calculators to account for whitespace before an empty child with nonzero margins.
• Fixed overlapping elements with flex box when height: 100% is applied on nested content.
• Fixed incorrect grid item positioning with out-of-flow sibling.
• Fixed break-word with a float discarding text.
• Fixed min-content calculation for unstyled only-child inlines elements.
• Fixed ellipsis rendering multiple times when position: relative and top are used.
• Fixed a bug for inline elements inserted in reverse order after a block in a continuation.
• Fixed the flash of a page background-colored bar in the footer when the window is resized.
• Fixed the cursor not updating as content scrolls under it on some pages.
• Fixed the SVG parser to interpret “form feed” as white space.
• Fixed error handling for invalid filter primitive references.
• Fixed displaying an SVG element inside a <switch> element.
• Fixed SVG title to have display: none as the default UA style rule.
• Fixed the UA stylesheet for links in SVGs to apply cursor: pointer matching standards.
• Fixed returning the initial value for the SVG gradient stop-color if it is not rendered in the page.
• Fixed the SVG marker segment calculations if the marker path consists of sub-paths.
• Fixed SVGLength to sync with the WebIDL specification.

Web Animations

• Fixed percentage transform animations when width and height are animated.
• Fixed updating an animation when changing the value of a transform property while that property is animated with an implicit keyframe.
• Fixed animating with color-mix .
• Fixed cssText setter to change the style attribute when the serialization differs.
• Fixed history.pushState() and history.replaceState() to ignore the title argument.
• Fixed URL text fragment directives not fully stripped from JavaScript.
• Fixed showPicker() method to trigger suggestions from a datalist .
• Fixed lang attribute in no namespace to only apply to HTML and SVG elements.
• Fixed unnecessarily unsetting the iframe fullscreen flag.
• Fixed DOM Range to correctly account for CDATASection nodes.
• Fixed getGamepads() to no longer trigger an insecure contexts warning.
• Fixed inserting a <picture> element displaying the same image twice.
• Fixed throwing exceptions in navigation methods if in a detached state.
• Fixed a minor issue in URL’s host setter.
• Fixed cloning of ShadowRoot nodes following a DOM Standard clarification.
• Fixed GeolocationCoordinates to expose a toJSON() method.
• Fixed GeolocationPosition to expose a toJSON() method.
• Fixed setting CustomEvent.target when dispatching an event.
• Fixed navigator.language only returning the system language in iOS 17.4.
• Fixed: Removed presentational hints from the width attribute for <hr> .
• Fixed resolving www. sub-domain for Associated Domains for all web apps.

Web Assembly

• Fixed initialization of portable reference typed globals.
• Fixed font sizes in the Audits tab.
• Fixed expanded sections of Storage to not collapse
• Fixed CSS font property values marked !important not getting overridden when using the interactive editing controls.
• Fixed an issue where the Web Inspector viewport might appear cut off.
• Fixed runtimes to be aligned in the Audit tab.
• Fixed remembering the message type selection in the Console tab.
• Fixed autocomplete for the text-indent property suggesting prefixed properties instead of each-line or hanging .
• Fixed background autocompletion suggestion to include repeating-conic-gradient .
• Fixed console clearing unexpectedly when Web Inspector reopens
• Fixed console code completion to be case-insensitive.
• Fixed overflow: scroll elements to scroll as expected when highlighting an element from the DOM tree.
• Fixed showing additional Safari tabs from an iOS device in the Develop menu.
• Fixed Console and code editor completion not auto-scrolling the suggestion into view.
• Fixed search in the DOM tree view unexpectedly chaning the text display.
• Fixed clicking the “goto” arrow for computed CSS when “show independent Styles sidebar” is disabled.
• Fixed inspectable tabs from Safari in the visionOS Simulator don’t appear in Developer menu on the host macOS.
• Fixed Gamepad API in WKWebView.
• Fixed repainting HTML elements when their width or height change in legacy WebView.
• Fixed VideoTrackGenerator writer to close when its generator track (and all its clones) are stopped.
• Fixed WebRTC AV1 HW decoding on iPhone 15 Pro.
• Fixed black stripes with screen sharing windows.
• Fixed black stripes with getDisplayMedia captured windows when the window is resized.

You can test Safari 18 beta by installing the beta of macOS 15, iOS 18, or iPadOS 18. Or, if you’d like, you can try out Safari 18 beta on macOS Sonoma or macOS Ventura by downloading the Safari 18 beta , once it’s available. (Sign in using a free Apple ID to download. Installing Safari 18 beta on macOS Sonoma or macOS Ventura will replace your existing version of Safari with no way to revert to an earlier version.) You can also help test many of these features in Safari Technology Preview .

We love hearing from you. To share your thoughts on Safari 18 beta, find us on Mastodon at @[email protected] and @[email protected] . Or send a reply on X to @webkit . You can also follow WebKit on LinkedIn . If you run into any issues, we welcome your feedback on Safari UI (learn more about filing Feedback ), or your WebKit bug report about web technologies or Web Inspector. If you notice a website that seems broken in Safari, but not in other browsers, please file a report at webcompat.com . Filing issues really does make a difference.

Download the latest Safari Technology Preview on macOS to stay at the forefront of the web platform and to use the latest Web Inspector features.

You can also find this information in the Safari 18 beta release notes .

• Skip to main content
• Skip to search
• Skip to select language
• Sign up for free

MediaRecorder: MediaRecorder() constructor

The MediaRecorder() constructor creates a new MediaRecorder object that will record a specified MediaStream .

The object can optionally be configured to record using a specific media container (file type), and, further, can specify the exact codec and codec configuration(s) to use by specifying the codecs parameter .

The MediaStream that will be recorded. This source media can come from a stream created using navigator.mediaDevices.getUserMedia() or from an <audio> , <video> or <canvas> element.

A dictionary object that can contain the following properties:

A MIME type specifying the format for the resulting media; you may specify the container format (the browser will select its preferred codecs for audio and/or video), or you may use the codecs parameter and/or the profiles parameter to provide detailed information about which codecs to use and how to configure them. Applications can check in advance if a mimeType is supported by the user agent by calling MediaRecorder.isTypeSupported() . Defaults to an empty string.

The chosen bitrate for the audio component of the media.

The chosen bitrate for the video component of the media.

The chosen bitrate for the audio and video components of the media. This can be specified instead of the above two properties. If this is specified along with one or the other of the above properties, this will be used for the one that isn't specified.

The bitrate mode that should be used to encode the audio. Can be constant , which indicates that the recorder should encode at a constant bitrate, or variable , which indicates that the recorder should encode using a variable bitrate, thus allowing more space to be used for complex signals and less space for less-complex signals. Defaults to variable .

The nominal interval in time between key frames in the encoded video stream. The user agent controls key-frame generation based on this option and the videoKeyFrameIntervalCount option.

The interval in number of frames between key frames in the encoded video stream. The user agent controls key-frame generation considering this option as well as videoKeyFrameIntervalDuration option.

Note: If bits per second values are not specified for video and/or audio, the default adopted for video is 2.5Mbps, while the audio default is adaptive, depending upon the sample rate and the number of channels.

Note: Video resolution, frame rate and similar settings are specified as constraints when calling getUserMedia() , not here in the MediaStream Recording API.

Thrown if the specified MIME type is not supported by the user agent.

This example shows how to create a media recorder for a specified stream, whose audio bit rate is set to 128 Kbit/sec and whose video bit rate is set to 2.5 Mbit/sec. The recorded media data will be stored in an MP4 wrapper (so if you gather the chunks of media data and save them to disk, they will be in an MP4 file).

Specifications

Browser compatibility.

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

• Using the MediaStream Recording API
• Web Dictaphone : MediaRecorder + getUserMedia + Web Audio API visualization demo, by Chris Mills ( source on GitHub .)
• simpl.info MediaStream Recording demo , by Sam Dutton .
• MediaDevices.getUserMedia