Add Threads as an oEmbed provider

[pmestevez]

Threads ​recently updated their oEmbed API to drop the access token requirement, making tokenless embedding possible via the graph.threads.com/oembed endpoint.

Trac ticket: https://core.trac.wordpress.org/ticket/64858

## Description
Adds Threads as a built-in oEmbed provider. Threads recently dropped the access token requirement, making tokenless oEmbed possible via graph.threads.com/oembed.

## Changes

• Registered two provider patterns in class-wp-oembed.php covering both URL formats
• Added documentation table entries
• Added PHPUnit test file with 14 test cases

## Supported URL formats

• https://www.threads.com/@{username}/post/{shortcode}
• https://www.threads.com/t/{shortcode}

Both threads.com and threads.net domains supported, with and without www., over http and https.

## Testing

PHPUnit tests included: 10 positive match tests + 4 negative tests.

Manual: paste a Threads post URL in the classic editor or via the REST API oEmbed proxy and verify the embed resolves.

## Use of AI Tools

Created using Claude Code (Opus 4.6)

[swissspidy]

Hi there and welcome to Trac!

We have a dedicated oEmbed questionnaire that we ought to fill out: ​https://make.wordpress.org/core/handbook/contribute/design-decisions/#adding-new-oembed-providers

At first glance I am very hesitant to add support because of the whole access stuff in the past. If they change their mind again one year from now then that's a bad user experience.

So perhaps for now this is better off in a plugin.

[pmestevez]

Hey @swissspidy - thanks for the feedback. I understand your hesitancy but hopefully I can provide the context to explain why adding support for Threads embeds to core is the right decision.

I support the team that build all the Threads APIs and also have knowledge of the process to add the access token requirements to Facebook and Instagram (which I believe is what you are mimicked the Instagram API and thus kept the access token requirement.

However, my team and I have taken the necessary steps to make the case that Threads should follow the industry standards and do NOT require access tokens for embeds. We secured the necessary approvals and launched the new version of the API, which is the new one used in this proposed change.

Regarding the questionnaire, is your request that I answer in this ticket all the questions listed in the handbook section that you link to?

Thanks!

Replying to swissspidy:

Hi there and welcome to Trac!

We have a dedicated oEmbed questionnaire that we ought to fill out: ​https://make.wordpress.org/core/handbook/contribute/design-decisions/#adding-new-oembed-providers

At first glance I am very hesitant to add support because of the whole access stuff in the past. If they change their mind again one year from now then that's a bad user experience.

So perhaps for now this is better off in a plugin.

[swissspidy]

Regarding the questionnaire, is your request that I answer in this ticket all the questions listed in the handbook section that you link to?

Yes.

[pmestevez]

Here is the filled out oEmbed questionnaire:

1. Is the service is popular enough for core developers to have heard of it before? Is it “mainstream?”

Yes. Threads is a mainstream Meta product, not a niche service or side project. In Meta’s Q4 2025 earnings materials, the company said Threads had reached 320 million monthly active users, and that Q4 optimizations drove a 20% lift in time spent. That is the kind of scale and ongoing investment that makes it reasonable to treat Threads as a durable mainstream platform.

2. If similar services are already supported, how does this service compare in terms of size, features, and backing?

Threads compares favorably with other large social/discussion platforms already familiar to WordPress users. It is backed by Meta, has hundreds of millions of monthly active users, and exposes a dedicated oEmbed capability for public posts through official developer documentation.

3. Does this service have an established social media presence?

Yes.

4. Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)

Yes. The initial endpoint was released in December of 2024 and the tokenless endpoint used by this proposed change was released in March of 2026. The endpoint is documented at ​https://developers.facebook.com/docs/threads/tools-and-resources/embed-a-threads-post

5. Does the oEmbed endpoint work with WordPress’ oEmbed auto-discovery? If not, could it be made to work with additional HTML tags or attributes being added to the allow-list?

Given the limitation on non-allowlisted sites and the variety of Threads supported content types, the right solution seems to be adding Threads as a supported provider.

6. Does the service make an effort to build relationships with developers, such as through robust APIs?

Yes. We have an active developer community and up to date documentation. My team has hosted six developer events across the world in 2024 and 2025.

7. How old is the service?

Threads launched in July 2023, so it is no longer brand new. More importantly, it has now had time to demonstrate continued investment, feature expansion, and user growth rather than a short launch spike followed by abandonment.

8. Does it have a well-established Wikipedia article? (Seriously.)

Yes. ​https://en.wikipedia.org/wiki/Threads_(social_network)

9. Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?

Yes. There is at least one dedicated WordPress.org plugin, Social Post Embed, whose stated purpose is to support Threads embeds until they become part of WordPress core. There is also broader ecosystem demand through large embedding plugins such as EmbedPress, which has 100,000+ active installations and markets support for embedding social content from many sources.

My team also works with a large number of publishers and we consistenyly hear demand for simpler ways to embed Threads posts.

10. Is the provider frequently proposed?

I don't have a lot of data points here but given the anecdotal evidence that my team has collected, the search results for tickets on this page, and the platform growth, I would say yes.

Please let me know if this works or if I should expand in any of the areas. I hope this helps!

[westonruter]

I suppose this could make it into 7.0, but I'm marking as Future Release pending feedback.

[peterwilsoncc]

I share @swissspidy's concern regarding Meta's past practices of privatizing public APIs. Facebook and Instagram were following industry oEmbed standards up until they weren't.

Maintaining Threads embeds in a plugin will at least allow for an API field to be added if a Meta business team makes the same decision in the future.

[pmestevez]

I understand your concern, @peterwilsoncc. However, as someone with historical context, my pitch is that the decision to add those to Facebook and Instagram came at a time when drastic measures were taken to deal with heavy restrictions.

For the record, it was not the case that a random business team decided that it was good for their goals to require an access token.

My team and I took the time to argue why that decision was extreme, have secured the necessary approvals for Threads, and in fact, we also plan to remove the access token requirement from the Facebook and Instagram APIs.

I hope that the community can understand that I represent the team that has advocated for the importance of having embeds available in platforms like WordPress, and that we don't base the decision to support Threads on what we are acknowledging as an extreme measure.

Happy to chat more!

[westonruter]

Replying to pmestevez:

My team and I took the time to argue why that decision was extreme, have secured the necessary approvals for Threads, and in fact, we also plan to remove the access token requirement from the Facebook and Instagram APIs.

This is very welcome news!

[pmestevez]

A quick update from my end. I looked into whether auto-discovery could be a fallback here, and I do not think it will work in practice because for non-allowlisted providers WordPress sanitizes the returned oEmbed HTML, strips the <script> tag, and then rejects the result if no <iframe> remains. Since the current Threads response is blockquote + script rather than iframe, discovery alone does not appear sufficient.

Separately, it'd be great to understand what the final process is for deciding whether a provider like Threads can be added as a supported oEmbed provider in core. It would also be helpful to understand the expected timeline for that decision, or whether there are specific remaining criteria this proposal needs to satisfy.

[swissspidy]

A quick update from my end. I looked into whether auto-discovery could be a fallback here, and I do not think it will work in practice because for non-allowlisted providers WordPress sanitizes the returned oEmbed HTML, strips the <script> tag, and then rejects the result if no <iframe> remains. Since the current Threads response is blockquote + script rather than iframe, discovery alone does not appear sufficient.

Thanks for the update. That makes sense to me.

While we might potentially make this less strict and allow plain blockquotes (#61127), the blockquote returned by the API is basically empty except for a "View on Threads" text, which isn't really useful.

Is its oEmbed endpoint clearly established and properly documented? (Sometimes, they are just a developer’s pet project that may not be supported.)

Yes. The initial endpoint was released in December of 2024 and the tokenless endpoint used by this proposed change was released in March of 2026. The endpoint is documented at ​https://developers.facebook.com/docs/threads/tools-and-resources/embed-a-threads-post

I just tried using the oEmbed endpoint at https://graph.threads.net/v1.0/oembed?url=https://www.threads.com/@paul.0key/post/DV_pLGWAugC

Unfortunately it does not obey the maxwidth and maxheight request parameters, as required by the spec (despite the docs saying otherwise). There is no height response field either. Some other fields are absent too but they're all optional, so that's fine.

Has anyone written a WordPress plugin that leverages the service in some way, whether adding it as an oEmbed provider, creating a shortcode, or leveraging other APIs of the service? Do these plugins have any noticeable adoption or traction that would indicate usage and demand?

Yes. There is at least one dedicated WordPress.org plugin, Social Post Embed, whose stated purpose is to support Threads embeds until they become part of WordPress core. There is also broader ecosystem demand through large embedding plugins such as EmbedPress, which has 100,000+ active installations and markets support for embedding social content from many sources.

Social Post Embed has 50+ active installs, and Social Post Embed does not support Threads specifically. Jetpack also doesn't appear to support it.

Is the provider frequently proposed?

I don't have a lot of data points here but given the anecdotal evidence that my team has collected, the search results for tickets on this page, and the platform growth, I would say yes.

With various site:wordpress.org searches I couldn't find anything.

My team and I took the time to argue why that decision was extreme, have secured the necessary approvals for Threads, and in fact, we also plan to remove the access token requirement from the Facebook and Instagram APIs.

I hope that the community can understand that I represent the team that has advocated for the importance of having embeds available in platforms like WordPress, and that we don't base the decision to support Threads on what we are acknowledging as an extreme measure.

That's great to hear indeed! I know how fast the wind can change at such a big company thoigh, so I'm sure you understand there will be still some reservations about this.

Separately, it'd be great to understand what the final process is for deciding whether a provider like Threads can be added as a supported oEmbed provider in core. It would also be helpful to understand the expected timeline for that decision, or whether there are specific remaining criteria this proposal needs to satisfy.

The earliest this could land is in WordPress 7.1, due in August.

From my perspective, the biggest concerns are oEmbed spec compliance and lack of trust because of past events. We don't want to have to remove this again after 3-4 years like we had to with the Facebook embeds.

We're generally more reserved towards adding new providers these days because of stories like that. There are always some security considerations as well since this allows inserting arbitrary unfiltered HTML. That's why plugins are a great way to add new providers and usually the recommended way before core adds support.

At the moment my suggestion is as follows:

• Threads to make sure maxwidth actually works and that the oEmbed endpoint generally follows the spec
• Embeds component maintainers to keep an eye on community adoption and feedback
• Maintainers to revisit this in June before 7.1 feature freeze

[pmestevez]

Replying to swissspidy:

While we might potentially make this less strict and allow plain blockquotes (#61127), the blockquote returned by the API is basically empty except for a "View on Threads" text, which isn't really useful.

Yeah, the blockquote is just a fallback. The script is the one that triggers loading the actual HTML. This is something that we could change to enable auto-discovery. My main concern is how to determine the dimensions of the iframe, but my team can take a look at this.

I just tried using the oEmbed endpoint at https://graph.threads.net/v1.0/oembed?url=https://www.threads.com/@paul.0key/post/DV_pLGWAugC

Unfortunately it does not obey the maxwidth and maxheight request parameters, as required by the spec (despite the docs saying otherwise). There is no height response field either. Some other fields are absent too but they're all optional, so that's fine.

The maxHeight parameter is documented as not supported; I believe it is not that uncommon. We'll take a look at the maxwidth one, since it should be respected within the documented supported range.

Social Post Embed has 50+ active installs, and Social Post Embed does not support Threads specifically. Jetpack also doesn't appear to support it.

Not sure if we were looking at the same Social Post Embed plugin. I was referring to ​this one, which explicitly mentions support of Threads.

That's great to hear indeed! I know how fast the wind can change at such a big company thoigh, so I'm sure you understand there will be still some reservations about this.

Yes, I do. To be fair, though, WordPress Core supports embeds from other big companies. My hope is that we don't infer a pattern from a single instance. You are preaching to the choir; we see the value and understand the importance and we did our homework.

The earliest this could land is in WordPress 7.1, due in August.

Understood. We can plan around that timeline and explore the auto-discovery and plugin routes in the mean time.

From my perspective, the biggest concerns are oEmbed spec compliance and lack of trust because of past events. We don't want to have to remove this again after 3-4 years like we had to with the Facebook embeds.

We're generally more reserved towards adding new providers these days because of stories like that. There are always some security considerations as well since this allows inserting arbitrary unfiltered HTML. That's why plugins are a great way to add new providers and usually the recommended way before core adds support.

I understand. I believe the size and the relevance of the platform warrants support in Core.

At the moment my suggestion is as follows:

• Threads to make sure maxwidth actually works and that the oEmbed endpoint generally follows the spec
• Embeds component maintainers to keep an eye on community adoption and feedback
• Maintainers to revisit this in June before 7.1 feature freeze

Sounds good. In addition to these, I will explore the possibility of returning a properly sized iframe. Thanks!

[westonruter]

Milestoning for visibility.