DeviantArt is the oldest big art community on the web, founded in 2000, owned by Wix since 2017 and at 110 million registered users by 2025. On 2 October 2026 we sent twenty requests to it through residential exits in the US, Germany, Japan, the UK and Brazil. Every profile and artwork page loaded on the first attempt over plain HTTP, with no challenge. So a proxy is not what stands between you and DeviantArt data. Weight is: one artwork page is 886 KB, while the official oEmbed endpoint returns the same title, views and favorites in 3.5 KB. And the terms say clearly what you may not do with the art: anything AI-related that the artist has not opted into.
What people search for
Google has no autocomplete at all for "deviantart proxies". "deviantart scraper" completes to github, image scraper, gallery scraper and, tellingly, "deviantart rules". "deviantart api" completes to api key, documentation, python, rate limit, access and upload api. People who type these want to collect galleries or images, and some of them already suspect there are rules.
The US results page for "deviantart proxies" is mostly about something else: DeviantArt tag pages and a Facebook group about proxy art for Magic: The Gathering, where a "proxy" is a home-made replacement card. The rest are a few proxy vendor pages with generic setup steps. The related searches are "Deviantart proxies free", "Deviantart proxies online" and "Deviantart proxies list". Nobody shows what DeviantArt actually returns to an automated client, so that is what we measured.
What DeviantArt serves to a proxied client
We used DeviantArt's own team account (/team, 361 artworks, 285,596 followers) and one of its posts, the ArtTober 2026 calendar, plus the three machine endpoints DeviantArt documents or exposes: RSS, oEmbed and the OAuth API.
| Request (2 October 2026) | Exit | Result | Bytes | Time |
|---|---|---|---|---|
| Team profile, plain HTTP | US | 200, 1st attempt | 1,929,900 | 2.7 s |
| Team profile, plain HTTP | Germany | 200, 1st attempt | 1,929,392 | 3.4 s |
| Team profile, plain HTTP | Japan | 200, 1st attempt | 1,928,987 | 7.4 s |
| Team profile, rendered | US | 200 | 1,638,277 | 20.3 s |
| Artwork page, plain HTTP | US | 200, 1st attempt | 886,446 | 13.1 s |
| Artwork page, plain HTTP | Germany | 200, 1st attempt, German interface | 949,379 | 8.5 s |
| Artwork page, plain HTTP | Japan | 200, 1st attempt | 910,210 | 3.9 s |
| Artwork page, rendered | UK | 200 | 1,235,310 | 24.1 s |
| RSS feed of the team gallery, 60 items | US | 200, 1st attempt | 356,489 | 1.4 s |
| oEmbed for the artwork | US | 200, 1st attempt | 3,545 | 4.6 s |
| robots.txt | US | 200, 1st attempt | 284 | 0.6 s |
| OAuth API profile call, no token | US | 401, "Must provide an access_token" | 120 | n/a |
The other eight requests were SEO audits of the same two pages from the US, Germany and Brazil, and the Terms of Service and API License pages, all 200 (the API License page on the second attempt). Nineteen of twenty requests returned 200; the only other answer was the 401 from the API, which is how an API without credentials is supposed to answer.
Three things stand out. First, there is no wall. DeviantArt sits behind a CDN, and residential exits from three continents got the full page every time, without retries. Second, the server-side HTML is complete: the no-JS audit of the profile counted 3,275 words against 1,577 after rendering, with the same title, description and canonical, and a ProfilePage JSON-LD block. You do not need a browser to read a public DeviantArt page. Rendering cost 20 to 24 seconds per page for nothing extra. Third, the pages are heavy. Almost all of the 886 KB of an artwork page is application state and markup; the meta description alone already carries the publish date, likes, views and tags.
Lighter doors: oEmbed, RSS and the API
DeviantArt's developer docs name two ways to integrate: the OAuth API and the oEmbed API. The RSS feeds are older and still answer. Each one is far cheaper than the HTML:
| Endpoint | What it returned | Bytes | Auth |
|---|---|---|---|
| oEmbed (backend.deviantart.com/oembed) | Title, author, image and thumbnail URLs, publish date, 25,728 views, 231 favorites, 15 downloads, tags, safety rating | 3,545 | None, cached 180 s |
| RSS (backend.deviantart.com/rss.xml) | 60 latest items of a gallery with title, link, date, rating, credit and full description HTML | 356,489 | None, cached 300 s |
| OAuth API (/api/v1/oauth2) | 401 without a token; full access after registering an app | 120 | client_id and client_secret |
| Artwork HTML page | Everything above plus comments, related art and the interface | 886,446 | None |
For one artwork, oEmbed is 250 times lighter than the page. For a gallery feed, RSS gives 60 items for less than half of one artwork page. The view counter also moved while we worked: 25,728 views in the oEmbed answer, 25,753 in the last audit about twenty minutes later, so any "views" number you store is a snapshot with a timestamp, not a fact.
The API docs set two technical rules worth knowing before writing a line of code. All clients must send a User-Agent and use HTTP compression, or they are rejected. And there is no fixed request limit: the API uses adaptive rate limiting and returns 429 when you go too fast, with exponential backoff (1 s, 2 s, 4 s) as the documented answer. The API License adds that you must not try to exceed those limits, and that DeviantArt may block or suspend access if you do.
What DeviantArt's rules say
The robots.txt is short (284 bytes). For every user agent it asks for a one-second crawl delay and disallows /api/, /download/, /checkout/, /global/, user and join URLs with query strings, and any URL with a cursor parameter, which is how infinite-scroll galleries page. It blocks Pinterestbot from the whole site. Public profiles and artwork pages are allowed. You can paste the file and a path into our ../../tools/robots-txt-tester/ to see the verdict for your own crawler.
The Terms of Service have a whole section on this, section 24, "Data Scraping & Machine Learning Activities". Unless an artist opts in, DeviantArt adds a robots meta tag with "noai" or "noimageai" to the page and an X-Robots-Tag "noai" header to media downloads. The ArtTober page we tested carried noimageai from Germany and Japan alike. Where those flags apply, third parties are prohibited from using the content to train an AI system, as input to an already trained one, or to republish derivative copies under looser conditions, and automated systems that ignore these choices are in breach of the terms. The terms also say plainly that the absence of the tag does not mean the artist consented.
So: reading public pages at a polite rate is within what robots.txt allows. Downloading the art to feed any AI pipeline is not, and their terms forbid it. A proxy changes neither answer. Collecting at scale through the API is allowed under the API License, with its own rate limits and attribution rules.
What changes by country
The content does not change. Title, description, canonical and counters were identical from the US, Germany, Japan and Brazil. What changes is the interface. From Germany, the artwork page came back with content-language "de" and an html lang of "de", 949,379 bytes against 886,446 from the US, because the labels around the art were in German. From Japan the same page came back in English. The profile page stayed English everywhere we tried.
That makes the useful geo job narrow but real: checking how your own gallery, shop or commission page reads to visitors in a market where DeviantArt localizes. For that, a country-targeted residential exit and a normal browser are enough. Wikipedia lists English, Spanish, German, French, Portuguese and Dutch among the available languages.
What a proxy is actually useful for on DeviantArt
| Job | Proxy type | Notes |
|---|---|---|
| See your own gallery or shop as visitors in another country see it | Residential, country-targeted | Germany got a German interface, Japan did not |
| Track views and favorites on your own or a brand's artworks | Often none: oEmbed answers directly | 3.5 KB per artwork; add a residential exit only if your servers get throttled |
| Find reposts of your art on other sites | Residential, through a reverse image search | Start from the image, not from DeviantArt |
| Run a brand or studio account from a stable address | Static ISP, one account per address | Consistency, not scale |
| Build a gallery archive or research dataset | None: use the OAuth API | Licensed, rate limited, attribution required |
| Download art to train or prompt an AI model | None | Forbidden by section 24 where noai or noimageai applies |
We used ../../residential-proxies/ for every request above and never needed a second attempt on a profile, artwork, feed or oEmbed request. We did not test mobile or datacenter exits in this run, so we make no claim about them. For a single studio account, ../../isp-proxies/ gives you the same address every session. If you want to check a site's protection yourself before planning anything, our ../../tools/waf-detector/ runs the same kind of test.
Errors you will see, and what each means
- 401 with "Must provide an access_token". 120 bytes of JSON. You called the OAuth API without a token. Register an app, do not retry from another address.
- 429 from the API. The adaptive rate limit. DeviantArt documents exponential backoff; rotating exits to dodge it is attempting to exceed the limits, which the API License forbids.
- A 200 page that is 1.6 to 1.9 MB. Not an error, but a cost: that is a normal profile. If you only need counters, switch to oEmbed.
- Robots meta "noimageai". Not an error, a rule: that artwork's image may not be used for AI purposes.
What it costs
Say a studio tracks 200 of its own artworks every day. Through the HTML pages: 200 x 886,446 bytes is 177.3 MB a day, about 5.32 GB a month, which at $0.80/GB on Residential Basic is about $4.26 a month. Through oEmbed: 200 x 3,545 bytes is 709 KB a day, about 21.3 MB a month, or under two cents through the same proxy, and often nothing at all, because oEmbed is meant to be called directly. Pulling the RSS feed of one gallery every hour is 356,489 x 24 x 30, about 257 MB a month, or about $0.21.
The lesson is the same as on most art sites: the format you choose moves the bill by two orders of magnitude, the proxy barely does. If what you need is to find where your images end up across the web, our ../../collectors/reverse-image-search-api/ collector does it and bills only successful results. For the neighbouring image networks, see our posts on ../pinterest-proxies/ and ../flickr-proxies/.