Threads Reply Approvals: When to Screen Replies and When Not To

Reply approvals is a moderation setting that holds every new reply to your post as pending until you review it. While a reply sits pending, nobody but you sees it. You get an activity notification for each one, and you work through them directly under the post using the Pending replies link.

The review actions are simple. Approve publishes the reply into your thread for everyone. Ignore keeps the reply hidden, and it stays hidden until you explicitly approve it later. There are also bulk actions for clearing a backlog in one move, plus per-profile options to mute, restrict, block, or report directly from the review queue.

Two mechanics matter more than people expect. First, the setting is per-post: the official Threads help page for reply approvals is explicit that you will need to manage this setting for each post, so there is no account-wide default to set once and forget. Second, approval is one-way: once approved, a reply cannot be returned to pending review, though you can still hide it afterward like any other reply.

The feature rolled out on October 30, 2025 alongside new activity feed filters, per reporting from 9to5Mac at launch. It sits next to the older who-can-reply control in the same Reply options menu, which is where most of the confusion starts.

For a new post, start drafting as usual. Before publishing, open Reply options in the composer and toggle Review and approve replies on. Changes save automatically. This is the cleanest moment to decide, because the second control in that same menu, who can reply, changes the conversation shape before it starts.

For a post that is already live, open the post, tap Options in the top right, then Reply options, and toggle approvals on. Meta's help page does not describe re-reviewing replies that are already visible, so if early replies are the concern, enabling approvals before publishing is the reliable path.

Reviewing happens from the post itself. Tap Pending replies below it to see the queue. From there you can approve individual replies, ignore them, open the More menu next to any reply for mute, restrict, block, or report, or use the bulk approve-all and ignore-all actions when the queue is long. You will be notified in Activity when new replies need review, so you do not have to watch the post continuously.

Turning approvals off follows the same path through Options and Reply options. Approved replies cannot return to pending review either way, per the help page. What happens to replies still waiting in the queue when you switch off is not spelled out there, so clear pending replies before toggling rather than leaving decisions half-made.

Approvals is one of four reply controls on Threads, and picking the wrong one is the most common setup mistake. The four are: limit who can reply, hide individual replies, approvals, and account-level tools like muted words and restrict. Meta documents the first as a way to manage who can reply and quote your post, per post, before or after publishing.

Limiting who can reply is preventive: it shrinks who may participate at all. Approvals works differently: everyone can still reply, and each reply then waits for you. That difference decides which one fits a given post better than any feature checklist.

Hiding is reactive. The help center calls it Hide for everyone, and it applies to a reply that is already public, removing it from under your post. Changing who can reply, separately, does not delete existing replies or quotes of your post; Meta notes those stay. For the account-level controls, mute, restrict, block, and hide each do different things to what the other person sees, and our guide to restrict vs block on Threads maps them out.

Approvals is the post-level screen: every new reply to that post waits for you before anyone else sees it. Hide acts after a reply is public. Account-level tools follow a person across posts. That positioning is exactly why approvals carries costs the others do not, which is the next section.

The first cost is attention. Every pending reply is a small decision you now own, and on a post that reaches beyond your usual circle the queue grows faster than a solo creator can clear it. If you enable approvals on everything, moderation stops being a task and becomes a shift. The bulk approve-all and ignore-all actions exist precisely because backlogs are expected.

The second cost is conversation speed. A public thread only grows when replies appear, and pending replies appear only when you approve them. Social Media Today's coverage of the rollout noted there is no public indicator that replies are waiting, so later readers simply see a quieter thread, while the person who replied is told that replies to the post require author approval. On a casual post, that delay costs more than the replies it filters.

The third cost is perception. The same coverage flagged the risk that screening replies could spark suggestions of censorship or avoidance of certain topics. If you use approvals, being consistent and even-handed about what passes protects the credibility the feature is supposed to help you keep.

None of these costs make approvals a bad tool. They make it a targeted one. The pattern that works is screening the few posts where unfiltered replies carry real risk, and letting the everyday majority run open, with hide for the odd bad reply and Hidden Words moving common offensive terms under a covered section automatically.

Use approvals when the post is high-stakes and the reply risk is real. The clearest cases: a company or personal announcement where wrong information in early replies can travel fast; an AMA or launch week when you are away from the phone; a post on a contested topic for a professional account; and a harassment window, when you know attention from bad-faith accounts is likely and want to slow the pile-on before it starts.

Skip approvals when the post is everyday and the worst likely reply is mildly annoying. If your recent posts average a handful of replies, screening adds a decision queue to a conversation that never needed one. Skip it too when speed is the point: a live reaction or a joke post lives on immediacy, and pending replies kill immediacy. For everyday negativity that does get through, a system for responding to negative comments costs less attention than screening everything.

And if your actual goal is more replies rather than fewer bad ones, screening works against you by design. Our reply-first growth strategy covers the earning side: the reply habits and post shapes that invite conversation in the first place. Approvals is for protecting a conversation you already expect to be rough, not for manufacturing a better one.

The middle ground is a hybrid. Keep the post open, but plan a moderation pass in the first hour: hide the worst, reply to the best, and only flip approvals on if the reply stream turns hostile. Because the setting can be enabled after publishing, you can treat it as an escalation step rather than a default stance. Six situations settle it fast: announcements, screen; AMA or launch week, screen; contested topic on a professional account, screen; harassment window, screen; everyday post with a mild worst case, stay open and hide as needed; speed-dependent post like a live reaction, stay open.

Here is the detail that catches experienced Threads users: posts that require approval for replies will not be shared to the fediverse, per Meta's help page. If you have turned on fediverse sharing, a post with approvals on stays off the federated timeline. The two features are mutually exclusive per post.

The order of operations matters. If a post has already been shared to the fediverse, you cannot turn approvals on for it at all; the setting is not available. Approvals also cannot pull back a post that already federated. So the decision is real: federation and reach on one side, screened replies on the other, and you choose per post which you want.

For most casual users this never comes up. But if you deliberately built a fediverse-aware presence, or part of your audience follows you from Mastodon or similar servers, enabling approvals changes who can see the post at all. That is a distribution decision disguised as a moderation setting, and it deserves a conscious choice, not an accidental one.

Approvals works best when it comes with a routine instead of an obligation to watch the phone. A workable rhythm for a screened post: check the pending queue once in the first hour after publishing, once more the same day, and once the next morning. On a normal post that is three short sessions, and the activity notifications mean nothing waits silently.

Decide fast using a two-question filter: is it on topic, and is it in bounds? On topic and in bounds, approve. On topic but hostile, ignore. Hide is for a reply that is already public, so it mostly comes into play on your open posts. Off topic but harmless gets approved anyway, because a comment section that only contains agreement looks curated in the bad way. Persistent bad actors get one of the account-level tools: mute, restrict, block, or report from the review queue itself.

Approve-all and ignore-all are backlog tools, not philosophies. Ignore-all after a spam wave is fine. Approve-all to clear a queue before a meeting is fine. What you want to avoid is approving everything by default just to keep up, because that is the moment the setting stops filtering anything and only adds delay to your followers' replies.

One more division of labor is worth setting up: separate your drafting time from your moderation time. Drafting the week's posts in one sitting, with the Free Threads Post Creator or your usual composer, keeps writing time from bleeding into queue time. If you find yourself screening every post anyway, the honest fix is not a faster routine. It is re-reading the decision framework above and letting most posts run open, with hide and the Hidden Words settings doing the quiet work.