AO3 News

Post Header

Last weekend, we had to disable new invitation requests to address an influx of accounts flooding the Archive with spam works. While our Abuse team has been banning these accounts and deleting thousands of spam works, the problem persists and would most likely get worse if we sent out invitations again.

We have decided to keep the invitation queue closed for the time being while we take steps to prevent spam from being posted in the first place. This means you will not be able to create an account unless you have previously received an invitation from either a friend or our automated queue. (If you requested an invitation before October 22 and have not received it, please check your spam folder and, if you use Gmail, your "Social" tab. If you are still unable to find your invitation, you can contact Support with your specific request.)

We very much regret denying invitations to legitimate users, but as the amount of spam being posted is affecting everyone's user experience, we currently see no other way to address the problem.

We will reopen invitation requests as soon as we can, although we do not have an estimated date at this time. When requests have been reenabled, the "Get Invited!" link will return to the homepage, and the Invitation Requests page will include a form to add yourself to waiting list. (The option to request invite codes for friends has been disabled since the last spam wave, and we have no plans to bring it back in the foreseeable future.)

Any updates will be provided on this post and our @AO3_Status Twitter account. For more information on the Archive's invitation system, refer to our Invitations FAQ.


Post Header

We're currently experiencing an influx of spammers who have been creating bogus works and collections to link to their fare. They've become highly adept at using Archive features, and they've been flooding our invite queue with throwaway email addresses to create new accounts. This keeps our Abuse team busy around the clock, deleting spam works as they pop up and trying to weed out obvious spam email addresses before invites are sent out every day. It also prolongs the wait time for everyone else who wants to join the Archive. Our wait list is inching ever closer to 20,000, meaning legitimate users have to wait almost three weeks to receive an invitation email.

As a short-term measure, we've decided to turn off the invite queue for a week, so we can relieve some of the burden on our Abuse team, discuss technical solutions to the problem, and implement a quick fix or two to help with the worst attacks.

If you are a current user, you can check your Invitations page to see if you have any old invites waiting to be sent to a friend or fellow fan.

We are sorry for the long wait times, and we're doing our best to come back soon and get invites out quicker to those currently waiting!

Update on October 23, 11:23 UTC: People who are currently waiting for an invitation should still receive an email while the queue is under review. If you think you should have received an invitation, please wait another day or two, check your spam folder or "Social" tab in Gmail, and use our look-up tool to see if you're still in the queue. If you're sure you should have received an invitation and didn't, you can contact our Support team.

Update on October 30, 23:08 UTC: Please refer to our post "Update: Invitation requests remain disabled for the time being" for the latest information regarding invitations.


Post Header

If you have podfic, fanvids, or other works with embedded media, users who currently opt to browse the Archive over HTTPS (e.g. via a browser extension) may be unable to access your work. Before we move the Archive to HTTPS, we'll be making some changes to existing audio and video embeds to prevent more widespread issues, but there are also steps you can take now to ensure your content loads for everyone.

The problem

Many of the media players in AO3 works use HTTP links to embed Flash files for playing back audio or video. For example, here's the code for an audio player that uses an HTTP URL as its src:

<embed type="application/x-shockwave-flash" flashvars="mp3=MP3_FILE_URL" src="" width="200" height="27" allowscriptaccess="never" allownetworking="internal"> </embed>

If someone uses HTTPS to access a work with code like that, their browser will notice a mismatch between the page they're on (HTTPS! secure!) and the content it's being asked to display (HTTP! not secure!). When this happens, many browsers will err on the side of security: they won't load or display the embedded media.

Most browsers do allow users to override this behavior and display insecure content, but how easy that is varies a lot from browser to browser, and the process can change from one browser version to the next. (A web search for "display mixed content" plus the name and version of your browser should provide the information you need.) Whenever possible, it's easier -- and safer -- to tell the browser to load the file over HTTPS.

What you can do

To help the browser out, you can simply add that little "s" to the relevant bit of your embed, which will create a secure connection to the file in question. The vast majority of our whitelisted multimedia players already offer HTTPS support. If you only have a few works with audio, video, or even image content which link to external media, you can edit your works, look for the src part and turn the http bit into an https. That's it!

This will ensure that everyone can access your podfic, fanvid, art, or other media, even if they're browsing the Archive in HTTP mode. (Browsers are cool with that mismatch.)

What we will do

Since we can't expect all our users to edit all their multimedia works by hand, we will ensure that all embeds use the correct linkage by doing one big find-and-replace on our end. Because we only allow embeds from a few sites, we can easily find the affected works by searching our database for specific HTML. Then we can run a few simple commands to update the embed code's src from http to https.

This will not touch the content of your work in any way, or alter anything about your work that isn't neatly bracketed by a pair of very specific quote marks. When it's all done, your content will be accessible to users browsing the Archive in secure mode, if it wasn't before. \o/

We are planning to do this on October 4th, right before we switch to HTTPS mode on the AO3.

To make sure that works posted from now on won't run into this problem, we've updated our code to ensure embeds use https links where available, and edited our documentation for audio player embeds.

Edit 09:24 UTC on 05 October, 2017: The update to embedded media files has been completed, but attempts to move the Archive to HTTPS were unsuccessful. HTTP will remain the default for a little while longer, and we'll update you via our Twitter account when we're ready to try again.

Edit 19:16 UTC on 12 October 2017: We successfully made the switch to HTTPS for a few days; however, the extra strain from encrypting all traffic proved too much for our servers at peak times. Until we have installed additional servers (coming soon!), HTTP will remain the default protocol. (Of course, you can still elect to use a secure connection, e.g. via a browser extension like HTTPS Everywhere.) Please follow @AO3_Status on Twitter for futher updates.

Edit 22:15 UTC on 14 October 2017: We have implemented the caching needed to reduce server strain and are currently back on the secure protocol by default. We believe we'll be able to remain on HTTPS, but if it proves too much, we will switch back until our new frontend servers arrive.


Post Header

If you've been following our release notes, you know that we have been working towards full HTTPS support on the Archive for a while now. Today, we're happy to announce that beginning on October 4th, all connections to the Archive will use HTTPS by default.

If you use a modern browser, you won't have to do anything -- we'll just flip a (virtual) switch to enforce a secure connection between your browser and our servers. As a result, all AO3 pages will display a lock symbol and/or a friendly little https:// in the address bar of your browser. Old http:// links to the Archive will automatically redirect to the secure version.

For users who might have trouble accessing secure websites, we will continue to provide HTTP access to the Archive -- via -- for as long as necessary. (You might still run into the odd HTTPS link on the site, for example when downloading a work as a PDF, MOBI, or EPUB file.)

We don't expect any downtime during this transition, and you shouldn't notice any changes. Just to be on the safe side, we will monitor our servers and firewalls and might temporarily revert back to HTTP mode should we notice any problems.

Please keep an eye on the @AO3_Status Twitter account for more updates as we get closer to the switch.

Happy (secure) browsing!

Edit 09:24 UTC on 05 October, 2017: The update to embedded media files has been completed, but attempts to move the Archive to HTTPS were unsuccessful. HTTP will remain the default for a little while longer, and we'll update you via our Twitter account when we're ready to try again.

Edit 19:16 UTC on 12 October, 2017: We successfully made the switch to HTTPS for a few days; however, the extra strain from encrypting all traffic proved too much for our servers at peak times. Until we have installed additional servers (coming soon!), HTTP will remain the default protocol. (Of course, you can still elect to use a secure connection, e.g. via a browser extension like HTTPS Everywhere.) Please follow @AO3_Status on Twitter for futher updates.

Edit 22:15 UTC on 14 October 2017: We have implemented the caching needed to reduce server strain and are currently back on the secure protocol by default. We believe we'll be able to remain on HTTPS, but if it proves too much, we will switch back until our new frontend servers arrive.


Post Header

2017-09-18 12:47:51 -0400

Shortly after we upgraded the Archive to Rails 4.2, users began reporting they were being redirected to the login page when submitting forms (e.g. bookmarking a work, or posting a comment). Our coders were unable to find the cause of this problem and hoped it would resolve itself when we upgraded to Rails 5.1.

Unfortunately, the upgrade did not fix the issue, and further research has revealed this is a bug within Rails itself. The bug mainly -- but not only -- affects iPhone Safari users, and is most likely to happen when submitting a form after closing and re-opening your browser, or after leaving a page open for a number of days.

There's currently no official fix for this issue, but you may be able to work around it by using your browser's "Back" button and submitting the form again. We'll also be implementing a temporary workaround on our end by making session cookies last two weeks. This means it is very important to log out of your account if you are using a public computer. If you simply close the browser and leave, you will still be logged in and the next person to use the computer will be able to access your account.

Once an official fix becomes available, we will apply it as soon as possible. There's no word on when this will be, but in the meantime, we'll keep looking for workarounds.

Update, 23 September 2017: If you have JavaScript disabled in your browser and were getting Session Expired errors when trying to log in, the problem should now be fixed!


Post Header

OTW contested election banner

The Elections Committee would like to thank all of our candidates for their hard work in this year's election. With that, we are pleased to present the results of the 2017 Election.

The following candidates (in alphabetical order) have been officially elected to the Board of Directors.

  • Claire P. Baker
  • Danielle Strong
  • Jessie Camboulives

The new members of the Board will formally begin their term overlap on October 1, 2017. We wish them well with their terms. With that, the election season comes to a close. Thank you to everyone who got involved by spreading the word, asking the candidates questions, and, of course, voting! We look forward to seeing all of you again next year.



Post Header

partial screenshot of the AO3 homepage showing 25000 fandoms with the AO3 logo above the text

Tag Wranglers are pleased to announce that we have reached the milestone of 25,000 fandoms on AO3! This comes shortly after we celebrated reaching 3 million fanworks in April and 1 million users back in October.

AO3 users have always been incredibly creative. Over the years, we've reached several fandom milestones:

  • 5,000 fandoms around New Year's Day, 2010
  • 10,000 fandoms in September, 2012
  • 15,000 fandoms in April, 2014
  • 20,000 fandoms in December, 2015

Are there any rare fandoms you love that you discovered on AO3?

Sharing 25,000 Fandoms with 1 Million People

With so many new fandoms, fanworks, and users joining us daily, now is a good time to explain what this growth can mean for users and Tag Wranglers.

Tags on AO3 are shared. If you use the same exact tag that someone else has used, your works will be included in the same filters. Tag Wranglers cannot separate works using the exact same tag. We can only wrangle tags, not works.

If you discover that your work is showing up under a different filter (tag) than you intended, you can edit the tag on your work to be clearer. For example, Penny Parker is a character on the TV show MacGyver. “Penny Parker” is also a common fan name for female Peter Parker, better known as Spider-Man. If you tag your work “Penny Parker”, it will end up in the filters for the MacGyver character, even if you were thinking of female Peter. To avoid this, you could alter your tag to “Penny Parker (girl!Peter)” or something similar. That would allow Tag Wranglers to merge it into Peter Parker’s tag filter instead.

(Obviously, Tag Wranglers can’t merge the plain “Penny Parker” tag directly with Peter’s. If we did that, all of the MacGyver’s “Penny Parker” works would show up in Peter Parker’s filters, and she would not have a filter of her own. This would cause problems for fans of both characters!)

If a tag is new to you, you might find it useful to check its filter before using it. You might find that the tag has a different meaning in a different fandom.

How To Make Tags Work For You

In the month of April this year, Tag Wranglers collectively wrangled approximately 497,000 tags. In May we wrangled well over half a million! Tag Wranglers work very hard to connect your tags; you can make our job easier by being clear about what you mean.

Here are some ideas you can try in order to make your own works or bookmarks appear in the filters you want. (Please don't comment on works to ask other users to do this - this is for your own works/bookmarks only!)

  • Autocomplete is your friend: If a fandom tag exists in the autocomplete for your fandom already, try including that tag. The tags that Tag Wranglers see are based on filterable fandoms listed on the work, so using a fandom tag from the autocomplete speeds up the time it takes to wrangle your tag and have it show up correctly.
  • Making a new fandom: If there is no fandom tag yet for your work, try including the medium, creator, or year the canon was first published in the tag. This speeds up the process of creating a new fandom tag, as we will have more information to use when researching what canon you mean! For books, it's especially important to include the author's name; for movies, the year. For other fandoms, usually the media type is enough, unless the title is very generic. For example, if you're posting for the TV show "Merlí", try adding "TV" after the title, like this: Merlí (TV).
  • Be kind to RPF fans: Try to avoid mixing up Actor RPF and fictional TV or movie fandoms in your tags. If you're posting Actor RPF, please use the RPF fandom tags. If an RPF fandom tag doesn't exist yet for that TV show or movie, make one by adding "RPF" to the end of the TV show or movie's existing tag name. Example: The Hunger Games (Movies) RPF. Please also try to avoid using the Actor RPF fandom tags if you're only working with fictional characters. This will help RPF fans easily find the works they want and will reduce the effort Tag Wranglers must use to find the right place for your tags.
  • Where does original work go? If you're posting a fannish-styled original work set in your own universe with your own characters, please try using the "Original Work" tag. (Furry fans, you can use that or the "Furry - Fandom" tag.) Please take care not to directly link to paypal, patreon, or commercial sites, as AO3 is a non-commercial site. (For further information, please consult the Terms of Service.)
  • Make characters unique: Try to use full names for characters. If a character has just one name, put the name of the fandom in parentheses after it. Example: Undyne (Undertale). This especially helps avoid any potential ambiguity issues and ensures that it will be easier to find your work. You may not think the chances of having a character named Undyne in another fandom is high, but this happens frequently.
  • Separate your / and & ships / is for romantic and/or sexual relationships. & is for platonic relationships only - ones that are neither sexual nor romantic. (Pre- and Post-Relationship are still /.) & was created for those Gen fans who don't want anything non-platonic in the ships they're searching for. You can help both Gen fans and shippers by carefully choosing the tag that matches your work!
  • Add cameos in the Additional Tags: If a fandom, character, or relationship is only a passing reference, you can choose to put the tag in the "Additional Tags" (Freeforms) category instead. This will keep your work from being sorted into the fandom, character, or relationship's filter, while still telling users what's in the work. Example: Hints of Jin Dong/Wang Kai in the "Additional Tags" field keeps Jin Dong/Wang Kai fans from being disappointed that a work only mentions their relationship briefly.

These suggestions are meant to help get your tags wrangled quicker and more accurately so that users have a great experience on AO3. You won’t need to edit any tags on past works or bookmarks unless they aren’t showing up in the filters you prefer.

However, these tagging suggestions don’t mean that you can’t continue to tag creatively for various topics! Tag Wranglers love clever tags, and sometimes we can even canonize the concepts. Magneto’s Terrible Fashion Sense is just one of many enjoyable tags that make us giggle.

If you have any questions or suggestions about wrangling, please consult the Tags FAQ. If that doesn't answer your question, the FAQ explains how to contact Tag Wranglers directly, or you can send short questions to us at our twitter account, ao3_wranglers.

Please don't leave comments on this post with questions or requests about specific tags. They won't be answered, since Tag Wranglers can't easily track requests from here. Please use the options listed above to contact us. Thanks!


Post Header

As you might have noticed if you're following our Release Notes, we've been focusing on humdrum back-end updates for quite a while now. Words like "test coverage" and "strong parameters" have featured prominently in every change log for almost a year, and we haven't been able to focus on more visible features and fixes. However, progress is being made, and thanks to your donations we have the financial means to work with contractors for a good part of these updates!

Having worked with a few other contractors in the past, primarily on smaller fixes to our codebase, we now have a stellar team that's been by our side for much of our big Rails upgrade, and will hopefully stay on for a few more projects after that. \o/

However, it's important to note that being able to afford contractors doesn't mean that all the work gets done right away. (Alas.) Our small team of volunteer coders and testers still has to thoroughly review and test all code submissions, while still living up to their pesky "real life" commitments. Bugs can still take days to solve, whether the person elbow-deep in code is being paid or not. And unforeseen problems affecting site stability and security still take precedence above all else, tying up volunteer time. (This is also the reason major code updates have been delayed for so long: there's always another fire to put out!)

As a result, the slog through our outdated code will take a while longer, and progress will seem slow from the user side. We are currently on Rails 3.2 and our upgrade will take us to the latest version of Rails 5. (Anyone familiar with Rails knows that this is quite a bit of work.) And once we’re done with the Rails work, we need to upgrade Elasticsearch, which powers the Archive's search and filtering functionality. After that's all done, we'll take a little nap we can go back to more exciting and significantly more visible projects!

We want to thank you for bearing with us through it all, and for the donations that make it possible to outsource some of the workload involved in updating the Archive code. We can't always reply to comments here, and we can't respond to every tweet (even if the reaction gif is really funny), but we see you, and we appreciate you. Thanks for your support over all these years! <3


Pages Navigation