AirPods microphone not working: verify the input before resetting the earbuds

Why successful playback does not prove microphone capture

An application can send sound to AirPods while receiving speech from the computer's built-in microphone, a webcam, or no permitted input at all. That distinction explains why a person may hear a call clearly while nobody hears them. Before cleaning or resetting anything, identify which microphone the affected application actually selected. A connected Bluetooth status alone does not answer that question.

Describe the symptom precisely. Completely silent speech, muffled speech, intermittent dropouts, and failure only when one earbud is worn are different patterns. Note whether the problem occurs in a meeting, a phone call, or a particular recording app. Also note whether it began after a device switch or after moving one earbud into its case. Those details shape a more useful comparison than a general statement that the AirPods stopped working.

This guide concerns AirPods and AirPods Pro earbuds, with model-dependent controls. AirPods Max and other headsets have different hardware and procedures. Do not apply a left-earbud microphone experiment or a charging-case reset sequence to a product that does not support it. Identify your exact model and consult the corresponding Apple support page before taking any maintenance action.

Prepare a short and private test

1. Charge the case and both earbuds through their intended charging method, then verify that each side shows charge when the paired device exposes individual status. Inspect whether an earbud is actually seated in its charging position. A case with charge does not by itself establish that both earbuds have been charging successfully.
2. Choose one source device and one quiet room for the baseline. Keep other paired devices from unexpectedly taking over through their normal connection controls if you can do so without disrupting anyone. Do not remove every pairing or sign out of an account at this stage. First preserve the state in which the symptom can be reproduced.
3. Use a neutral sentence with no personal information, spoken at an ordinary call level. Do not shout, blow into the microphone openings, or tap the earbuds. Keep hair, clothing, and hands away from the microphone area during the first comparison, then return to normal use later to see whether everyday movement changes the result.
4. Leave or mute a live meeting before testing elsewhere. Obtain consent before making any recording that could capture another person's voice. MeterSee's current microphone tool analyzes samples locally without recording or uploading them; if you need playback, use a separate trusted recorder and check which input that recorder actually uses.
5. Note the AirPods model, source device, operating-system version, application, selected microphone, and current automatic or side-specific microphone setting when available. Keep output volume comfortable if you later listen to a sample. Stop using equipment that is wet, damaged, unusually hot, or has a swollen battery, and follow manufacturer service guidance.

Verify the microphone selection in the affected application

Open the application's audio settings and inspect its microphone menu. Select AirPods explicitly when the app offers that choice, then speak the prepared sentence and look for its activity indication. If AirPods are absent as an input but present as an output, record that distinction. It may reflect the current connection, client, or supported input route; it is not automatically proof that the earbuds' microphones are physically broken.

If the application offers only a system default input, inspect the operating-system input rather than its output. On current macOS releases, System Settings, Sound, Input is the relevant selection area; older releases use System Preferences. Windows 11 generally exposes input under Settings, System, Sound. Device labels and Bluetooth endpoint presentation vary with software and hardware, so select what your system actually exposes instead of searching for one universal endpoint name.

After selecting an input, repeat a short phrase and confirm the app responds to your voice. An active level meter means some signal reached that application's capture stage. It does not establish intelligibility at the remote end or identify which earbud microphone is active when the operating system abstracts that choice. Ask a consenting listener for a brief confirmation in the real call after the local comparison.

Do not use tapping a laptop or rubbing an earbud as your principal identification test. Handling noise can travel through surfaces or be picked up acoustically, making the result ambiguous. Device labels, explicit selection, and a controlled supported input comparison provide a cleaner starting point. If the application never reveals its input and the platform documentation does not clarify it, label the microphone source uncertain.

Check permission and mute state separately

A browser meeting needs permission for its own site, and the browser application may also need operating-system microphone access. Check the affected site's address-bar permission controls rather than assuming a successful test on another website granted access everywhere. In macOS, application access is under System Settings, Privacy and Security, Microphone. In Windows 11, look under Privacy and security, Microphone, including desktop-app access where applicable.

On iPhone and iPad, application microphone permissions are generally listed under Settings, Privacy and Security, Microphone on current releases. The app may also have an in-call mute state or an audio-route control. Labels vary by version and application, and some system call workflows do not behave like a third-party recorder. Follow the affected app's own controls rather than assuming that every recording button captures the Bluetooth input.

If permission is blocked by school or workplace management, ask the administrator for the intended configuration. Do not remove profiles or security software to bypass the restriction. A permission error is evidence about access, not a microphone repair diagnosis. Preserve unrelated privacy choices and grant microphone access only to the trusted applications and sites needed for the test.

Check the meeting's mute icon and any supported AirPods call control that may affect mute in your particular device-and-app combination. Controls differ by generation and software support, so verify the visible call state rather than relying on an assumed gesture. If the app says muted, unmute through its interface for the baseline and see whether the activity indicator responds before changing Bluetooth settings.

Use MeterSee as a bounded capture comparison

Open MeterSee Microphone Test in a supported secure browser context and allow microphone access if you choose to use it. The first successful capture populates the input list; initially only the system default may appear. Stop that initial stream, select AirPods when exposed, and start a fresh run. Speak normally with a brief quiet pause, then stop. Expect a level responding to speech and retained browser-signal observations. If access fails, record the error and investigate permission or device availability first.

The page does not record a voice memo, play your voice back, or transmit a test call. Its levels are digital dBFS estimates, not a measure of the loudness of your voice in the room. Browser processing, including requested automatic gain, noise suppression, and echo cancellation, affects the samples. A quiet or clean-looking result cannot certify the AirPods' acoustic performance or every microphone inside them.

Compare the built-in microphone as a separate input if it is available. If the built-in input responds in the same browser while the explicitly selected AirPods input does not, the problem is more specific to the AirPods capture route. If neither works and the page reports blocked access, permissions deserve attention first. Keep those cases distinct instead of interpreting every flat meter as the same hardware failure.

Stop one capture before opening another application for the next comparison. If an app cannot access the device while another is using it, a simultaneous test may introduce a conflict that was not present in normal use. Closing unnecessary capture apps normally and repeating can be informative. Do not force-stop system audio services or run administrator commands as the first response to a browser capture error.

Compare automatic, left and right microphone settings when supported

Apple documents automatic microphone selection and fixed left or right choices for supported AirPods earbuds. On a paired iPhone or iPad, open the AirPods settings, commonly through Settings, Bluetooth and the information button beside the device, or the AirPods entry shown in Settings. Locate Microphone if that control is available; if it is not displayed, first open Audio & Routing as Apple directs. Preserve the original choice before making a temporary comparison.

With both earbuds charged and worn normally, select the left microphone option and repeat the same sentence in an application whose input route you have verified. Then select the right option and repeat under the same conditions. Record whether each produces speech, silence, or a different intermittent symptom. The purpose is a side-associated comparison, not an acoustic ranking or a measure of microphone sensitivity.

Apple notes that a fixed microphone choice can continue to designate that side even when it is removed or placed in the case. That makes the setting important when someone uses only one earbud. After the comparison, restore Automatic unless you intentionally need a documented temporary side-specific arrangement. Do not leave a fixed setting unnoticed and later mistake its behavior for a new random failure.

If one side repeatedly fails while the other works in the verified application, repeat once after normal charging and connection checks. That pattern is useful for Apple support, but it does not prove whether the cause is debris, side-specific connection state, damage, or an internal component. If the control is unavailable for your model or current platform, do not invent an equivalent through an unsupported utility. Mark the side comparison unavailable.

Investigate muffled speech and intermittent behavior

If speech is present but muffled, inspect the external microphone openings for visible debris in good light. Use only Apple's cleaning instructions for your exact AirPods model and generation. Do not poke mesh with a pin, apply generic solvent advice, use compressed air, or immerse an earbud based on instructions meant for another product. Cleaning methods and permitted materials differ, and this guide does not replace the model-specific procedure.

Repeat in a quiet room with a stable fit and without clothing or hair brushing the earbuds. Then compare your ordinary environment. If the voice becomes unreliable only in wind or heavy background noise, describe that environment-dependent result instead of declaring the microphone permanently dead. Application processing can influence what remote listeners hear, so keep the same app while comparing environments whenever practical.

If failures occur around automatic device switching, choose one source deliberately and repeat with other optional source connections inactive through their normal controls. Verify the selected input again after reconnecting. A call that silently moved to another microphone is different from an AirPod that stopped capturing. Do not repeatedly forget devices before observing which source and input were actually active when the symptom appeared.

On a Mac, opening an application that uses a Bluetooth headset microphone can change listening quality. Apple documents that behavior, so thinner playback during a microphone test is not by itself proof of a failed microphone. Assess outgoing speech separately from incoming music quality. A separate built-in microphone with AirPods as output can be a temporary workflow comparison when the application supports independent selections.

Compare another application or source before resetting

Try another supported application on the same source, explicitly verifying its input. A recorder that silently uses the phone microphone cannot establish that AirPods capture succeeded. If the second application receives AirPods speech and the original does not, focus on the original application's permissions, selection, and supported Bluetooth behavior. Keep the successful local result separate from an untested remote call path.

If another compatible source is available, pair or connect according to Apple's normal instructions only when you are authorized and have time to restore your setup. Repeat the same verified-input speech test. A failure that follows the same AirPods side across sources is stronger device-associated evidence than a failure in one browser tab. A successful second source instead directs attention back toward the original source's connection or application state.

Consider a model-specific restart, reconnection, update check, or reset only after documenting these results. Reset procedures differ, and forgetting a device changes pairing state that you may need to rebuild. Do not promise that a reset will repair a microphone or follow a button sequence intended for another generation. Use Apple's current instructions for the identified model and repeat the baseline afterward.

Hypothetical worked cases

Hypothetical case one: a laptop user hears a meeting through AirPods, but its input menu still points to a disconnected USB microphone. Selecting the available AirPods input restores a moving activity indicator and a consenting participant confirms speech. This supports an application-routing error in that setup. It does not mean that successful music playback had already tested the microphone, and a reset was unnecessary for this comparison.

Hypothetical case two: a person uses only the right earbud while the saved microphone setting is fixed to the left. They document the setting, restore Automatic, and repeat a verified-input call check. Speech becomes available in that arrangement. The useful conclusion is that the fixed-side configuration contributed to the symptom. It does not establish that the left microphone is damaged or that Automatic is guaranteed to solve every single-earbud problem.

Hypothetical case three: verified left-microphone selection repeatedly produces no usable speech on two compatible sources, while right selection works in both. Both earbuds show charge, and permission is confirmed in each app. The user collects those comparisons for Apple support rather than opening the earbud or repeatedly increasing gain. The pattern is side-associated evidence, not a browser-generated diagnosis of a particular internal part.

Hypothetical case four: AirPods speech works in a permitted local browser check but remains silent in a meeting site with blocked access. Allowing that meeting site's microphone permission and rejoining restores the intended capture. This illustrates that each site's permission matters. The local test was useful, but it had not verified the meeting's authorization, transmission, or remote intelligibility.

Frequently asked questions and service handoff

Can I use the working side temporarily? A supported fixed-side setting may help when that side consistently works, but document the limitation and remember what happens when you remove or case that earbud. Treat it as a temporary configuration, not proof that the other side has been repaired. Restore your preferred normal setting after service or after a successful retest.

Does a high browser level mean callers hear me clearly? No. Digital level alone does not establish clarity, correct transmission, or remote playback. The browser may also be receiving a different microphone unless you verified selection. Finish with a short two-way confirmation in the actual application, and describe any missing remote test as unverified rather than relying on a local meter.

What should Apple or application support receive? Provide the exact AirPods model, source and operating system, app, input selection, permission state, charge observations, and whether automatic, left, or right selection was tested. Distinguish silence from muffled speech or intermittent loss. Include cross-application and cross-source results actually completed, omit private call content, and state which comparisons were unavailable. That record is more actionable than a long list of resets with no preserved baseline.