` for `#!html ` tags with attribute `class="artisttag"`
+* search beneath those `#!html ` tags for `#!html ` tags
+* and then get the string content of those `#!html ` tags
+
+Changing the `artisttag` to `charactertag` or `generaltag` would give you `samus aran` or `blonde hair`, `blue eyes`, `bodysuit` respectively.
+
+You might be tempted to just go straight for any `#!html ` with `class="artisttag"`, but many sites use the same class to render a sidebar of favourite/popular tags or some other sponsored content, so it is generally best to try to narrow down to a larger `#!html
` container so you don't get anything you don't mean.
+
+### the ui
+
+Clicking 'edit formula' on an HTML formula gives you this:
+
+
+
+You edit on the left and test on the right.
+
+### finding the right html tags
+
+When you add or edit one of the specific tag search rules, you get this:
+
+
+
+You can set multiple key/value attribute search conditions, but you'll typically be searching for 'class' or 'id' here, if anything.
+
+Note that you can set it to fetch only the xth instance of a found tag, which can be useful in situations like this:
+
+```html
+
+ +
+ -
+ blonde hair (3456)
+
+```
+
+Without any more attributes, there isn't a great way to distinguish the `#!html ` with "blonde hair" from the other two--so just set `get the 3rd tag` and you are good.
+
+Most of the time, you'll be searching descendants (i.e. walking down the tree), but sometimes you might have this:
+
+```html
+
+
+ )
+
+
+```
+
+There isn't a great way to find the `#!html ` or the `#!html ` when looking from above here, as they are lacking a class or id, but you can find the `#!html ![]()
` ok, so if you find those and then add a rule where instead of searching descendants, you are 'walking back up ancestors' like this:
+
+
+
+You can solve some tricky problems this way!
+
+You can also set a String Match, which is the same panel as you say in with URL Classes. It tests its best guess at the tag's 'string' value, so you can find a tag with 'Original Image' as its text or that with a regex starts with 'Posted on: '. Have a play with it and you'll figure it out.
+
+### content to fetch
+
+Once you have narrowed down the right nodes you want, you can decide what text to fetch. Given a node of:
+
+```html
+Forest Glade
+```
+
+Returning the `href` attribute would return the string "(URL A)", returning the string content would give "Forest Glade", and returning the full html would give `#!html Forest Glade`. This last choice is useful in complicated situations where you want a second, separated layer of parsing, which we will get to later.
+
+### string match and conversion
+
+You can set a final String Match to filter the parsed results (e.g. "only allow strings that only contain numbers" or "only allow full URLs as based on (complicated regex)") and String Converter to edit it (e.g. "remove the first three characters of whatever you find" or "decode from base64").
+
+You won't use these much, but they can sometimes get you out of a complicated situation.
+
+### testing
+
+The testing panel on the right is important and worth using. Copy the html from the source you want to parse and then hit the paste buttons to set that as the data to test with.
+
+## json { id="json_formula" }
+
+This takes some JSON and does a similar style of search:
+
+
+
+It is a bit simpler than HTML--if the current node is a list (called an 'Array' in JSON), you can fetch every item or the xth item, and if it is a dictionary (called an 'Object' in JSON), you can fetch a particular entry by name. Since you can't jump down several layers with attribute lookups or tag names like with HTML, you have to go down every layer one at a time. In any case, if you have something like this:
+
+[](images/json_thread_example.png)
+
+!!! note
+ It is a great idea to check the html or json you are trying to parse with your browser. Some web browsers have excellent developer tools that let you walk through the nodes of the document you are trying to parse in a prettier way than I would ever have time to put together. This image is one of the views Firefox provides if you simply enter a JSON URL.
+
+Searching for "posts"->1st list item->"sub" on this data will give you "Nobody like kino here.".
+
+Searching for "posts"->all list items->"tim" will give you the three SHA256 file hashes (since the third post has no file attached and so no 'tim' entry, the parser skips over it without complaint).
+
+Searching for "posts"->1st list item->"com" will give you the OP's comment, \~AS RAW UNPARSED HTML\~.
+
+The default is to fetch the final nodes' 'data content', which means coercing simple variables into strings. If the current node is a list or dict, no string is returned.
+
+But if you like, you can return the json beneath the current node (which, like HTML, includes the current node). This again will come in useful later.
+
+## compound { id="compound_formula" }
+
+If you want to create a string from multiple parsed strings--for instance by appending the 'tim' and the 'ext' in our json example together--you can use a Compound formula. This fetches multiple lists of strings and tries to place them into a single string using `\1` regex substitution syntax:
+
+
+
+This is a complicated example taken from one of my thread parsers. I have to take a modified version of the original thread URL (the first rule, so `\1`) and then append the filename (`\2`) and its extension (`\3`) on the end to get the final file URL of a post. You can mix in more characters in the substitution phrase, like `\1.jpg` or even have multiple instances (`https://\2.muhsite.com/\2/\1`), if that is appropriate.
+
+This is where the magic happens, sometimes, so keep it in mind if you need to do something cleverer than the data you have seems to provide.
+
+## context variable { id="context_variable_formula" }
+
+This is a basic hacky answer to a particular problem. It is a simple key:value dictionary that at the moment only stores one variable, 'url', which contains the original URL used to fetch the data being parsed.
+
+If a different URL Class links to this parser via an API URL, this 'url' variable will always be the API URL (i.e. it literally is the URL used to fetch the data), not any thread/whatever URL the user entered.
+
+
+
+Hit the 'edit example parsing context' to change the URL used for testing.
+
+I have used this several times to stitch together file URLs when I am pulling data from APIs, like in the compound formula example above. In this case, the starting URL is `https://a.4cdn.org/tg/thread/57806016.json`, from which I extract the board name, "tg", using the string converter, and then add in 4chan's CDN domain to make the appropriate base file URL (`https:/i.4cdn.org/tg/`) for the given thread. I only have to jump through this hoop in 4chan's case because they explicitly store file URLs by board name. 8chan on the other hand, for instance, has a static `https://media.8ch.net/file_store/` for all files, so it is a little easier (I think I just do a single 'prepend' string transformation somewhere).
+
+If you want to make some parsers, you will have to get familiar with how different sites store and present their data!
\ No newline at end of file
diff --git a/docs/downloader_parsers_full_example_api.md b/docs/downloader_parsers_full_example_api.md
new file mode 100644
index 00000000..d642f178
--- /dev/null
+++ b/docs/downloader_parsers_full_example_api.md
@@ -0,0 +1,45 @@
+# api example
+
+Some sites offer API calls for their pages. Depending on complexity and quality of content, using these APIs may or may not be a good idea. Artstation has a good one--let's first review our URL Classes:
+
+ 
+
+We convert the original Post URL, [https://www.artstation.com/artwork/mQLe1](https://www.artstation.com/artwork/mQLe1) to [https://www.artstation.com/projects/mQLe1.json](https://www.artstation.com/projects/mQLe1.json). Note that Artstation Post URLs can produce multiple files, and that the API url should not be associated with those final files.
+
+So, when the client encounters an 'artstation file page' URL, it will generate the equivalent 'artstation file page json api' URL and use that for downloading and parsing. If you would like to review your API links, check out _network->downloader definitions->manage url class links->api links_. Using Example URLs, it will figure out which URL Classes link to others and ensure you are mapping parsers only to the final link in the chain--there should be several already in there by default.
+
+Now lets look at the JSON. Loading clean JSON in a browser should present you with a nicer view:
+
+
+
+I have highlighted the data we want, which is:
+
+* The File URLs.
+* Creator, title, medium, and unnamespaced tags.
+* Source time.
+
+JSON is a dream to parse, and I will assume you are comfortable with Content Parsers from the previous examples, so I'll simply paste the different formulae one after another:
+
+
+
+Each image is stored under a separate numbered 'assets' list item. This one has just two, but some Artstation pages have dozens of images. The only unusual part here is I also put a String Match of `^(?!.*assets\/covers).*$`, which filters out 'cover' images (such as on [here](https://www.artstation.com/projects/3KyXA.json)), which make for nice portfolio thumbs on the site but are not interesting to us.
+
+
+
+This fetches the 'creator' tag. Artstation's API is great because it includes profile data in content requests. There's the creator's presentation name, username, profile link, avatar URLs, all that inside a regular request about this particular work. When that information is missing (like in yiff.party), it may make the API useless to you.
+
+
+
+
+
+
+
+These are all simple. You can take or leave the title and medium tags--some people like them, some don't. This example has no unnamespaced tags, but [this one](https://www.artstation.com/projects/XRm50.json) does. Creator-entered tags are sometimes not worth parsing (on tumblr, for instance, you often get run-on tags like #imbored #whatisevengoingon that are irrelevent to the work), but Artstation users are all professionals trying to get their work noticed, so the tags are usually pretty good.
+
+
+
+This again uses python's datetime to decode the date, which Artstation presents with millisecond accuracy, ha ha. I use a `(.+:..)\..*->\1` regex (i.e. "get everything before the period") to strip off the timezone and milliseconds and then decode as normal.
+
+## summary { id="summary" }
+
+APIs that are stable and free to access (e.g. do not require OAuth or other complicated login headers) can make parsing fantastic. They save bandwidth and CPU time, and they are typically easier to work with than HTML. Unfortunately, the boorus that do provide APIs often list their tags without namespace information, so I recommend you double-check you can get what you want before you get too deep into it. Some APIs also offer incomplete data, such as relative URLs (relative to the original URL!), which can be a pain to figure out in our system.
\ No newline at end of file
diff --git a/docs/downloader_parsers_full_example_file_page.md b/docs/downloader_parsers_full_example_file_page.md
new file mode 100644
index 00000000..85ffa651
--- /dev/null
+++ b/docs/downloader_parsers_full_example_file_page.md
@@ -0,0 +1,99 @@
+# file page example
+
+Let's look at this page: [https://gelbooru.com/index.php?page=post&s=view&id=3837615](https://gelbooru.com/index.php?page=post&s=view&id=3837615).
+
+What sorts of data are we interested in here?
+
+* The image URL.
+* The different tags and their namespaces.
+* The secret md5 hash buried in the HTML.
+* The post time.
+* The Deviant Art source URL.
+
+## the file url { id="the_file_url" }
+
+A tempting strategy for pulling the file URL is to just fetch the src of the embedded `#!html ![]()
` tag, but:
+
+* If the booru also supports videos or flash, you'll have to write separate and likely more complicated rules for `#!html