A tool page can state exactly what input a feature accepts and what it outputs, but it cannot answer the other kind of question: whether I should use it for the job in front of me, and how to read what it gives me. The notes cover that second half: the problem really happened, how I narrowed it down at the time, what I based the judgement on, and in which situation the conclusion flips. The division is fixed: tool pages say what a feature can do, articles say when to use it, and the same subject is two separate pieces of content on the two sides, neither completing the other. That is the relationship people mix up most on a first visit. This page does not solve a specific error; it covers three things: the two shapes of content, what each of the three categories collects, and which words to search with when you cannot remember a tool name.
1. The address tells you which kind of page this is
Look at the path first. Tool pages sit at the root, like /json-format; articles all live under /notes/, like /notes/json-format-guide. The same subject has a page on each side, and the addresses differ only by that prefix. The address bar is therefore the first filter: with /notes/, the page is describing a judgement process and parameters appear only where needed; without the prefix it is a feature page you can read through and decide whether it works.
The site currently has 101 tool pages and 58 articles, and that gap is itself the editorial rule: not every feature gets an article. Inside the articles there is a second split, and this one affects how you use them more than the categories do.
- One kind is a single-tool problem note. The title is the error or confusion of that moment, and the body explains what the input looked like, why this tool was chosen, and under what condition it returns a result you should not quote directly. An API response flattened into one line with a value to find inside it belongs here: first how to read that shape, then JSON Formatter to expand or collapse the response.
- The other kind is a complete workflow across several features, where a job runs from start to finish through several tools and no single page explains the whole. These articles state why the next feature was needed, which is something a tool page never covers.
Whenever an article mentions a feature it links back to that feature's own page, averaging one to three such links per article. You can treat the article as a route map and the tool page as the destination: click through when you are ready to work, stay in the sentence when you only want the principle.
2. What each of the three categories collects
There are only three categories, and the boundaries are drawn by what is collected, not by discipline. The table below is the actual scope of this section.
| Category | Scope | Typical question shape | Examples in the body |
|---|---|---|---|
| Technical notes (31) | Data formats, text rules, encoding, filenames and paths | It errors as soon as I paste it and I cannot see where; two strings look identical but compare as different | An API response flattened into one line makes no sense; how to build a path when the filename has spaces or Chinese characters |
| Life essays (13) | Numbers you need in daily life but have no formula for at hand | Only the conditions are known, and you want the result plus whether the method can be trusted | How many days until the new year; how to work out fractions and permutations without getting tangled |
| Resource sharing (14, including this one) | Deliverables such as images, QR codes, barcodes and old photos | The thing already exists and must be made usable in the next step without redoing it | How far to compress an image before it blurs; enlarging an old photo turns it mushy |
Technical notes take 31 pieces, the largest block, and almost none of them are about how to write code; they are about why a piece of data is wrong. The traps along JSON, regex, encoding and paths mostly come from one misjudgement: treating one format as another, or checking by eye characters that do not actually match. Those bodies usually lay out the literal characters, because description alone cannot settle it.
Life essays are only 13, and the questions are more concrete: how fractions work, when permutations should not be multiplied, whether a holiday countdown includes the day itself, how to derive a sexagenary year. What they share is that no formula is at hand and the result has to be shown to someone else, so these bodies state how rounding and boundaries are fixed instead of dropping a single number.
The 14 pieces in resource sharing include this guide. Their trait is that the deliverable is already in the reader's hands, so the problem is rarely that the thing does not exist, but that what was produced does not work in the next step. How far to compress an image before it blurs, old photos going mushy when enlarged, a code that will not scan once printed: the answer depends on where it is going, not on any default.
3. When you cannot recall a tool name, search by problem
Tool names are the site's vocabulary, problems are your own, and the two often fail to meet. What you are really looking for is not the feature you used last time but how the title of this kind of article is phrased. Titles are written from the sentence of confusion, such as who appears on only one of the two lists. Turning your confusion into one sentence and matching it against titles is usually faster than scrolling a list of tool names.
A few rewrites you can apply directly:
- Change make the image smaller into the image goes blurry after compression. The second sentence is the shape of the problem and closer to a title; the feature you need is Image Compressor.
- Change how do I compare two lists into who appears on only one of them. The first has no match in a feature name, the second lands on an article title almost word for word.
- Before sending content out, ask a different question: is there anything in here that should not be shown to others. Screenshots and logs carrying phone numbers, names or addresses are handled in Privacy Masking, and the article explains which fields must be blocked and how far you can block them while still being able to check them back.
The address also confirms you are on the right page: when a search result appears, check for the /notes/ prefix. If it is there you are reading the reasoning; if not, you are already on a feature page.
4. Update rhythm and category boundaries
The category names are fixed at three and a fourth will not be added. Content accumulates on two triggers: a new feature goes live, or the same kind of problem keeps coming up, and only then does a new piece appear. There is no fixed schedule and no periodic promise, because a usable record needs more information than the words it has been updated.
Some pieces look like two categories at once, and then what you are holding decides. A piece of data or an error in hand means technical notes; a file, image or code you have to deliver means resource sharing; neither, and you only want to check a number you worked out yourself, means life essays. That line is drawn by input, which is less trouble than arguing about whether something counts as technical.
5. Common questions
Q: How are articles different from tool pages, and which should I read first?
A tool page answers what a feature can do; an article answers when to use it and how to read the result. If you are ready to work, start with the tool page, which is more precise about input and output; if you are still deciding whether a feature exists for this job, start with the article, which contains the part someone else already ran into.
Q: I cannot remember the tool name, only the problem. What then?
Put the problem into one complete sentence and match it against article titles. Titles are written from the confusion of the moment, such as how far to compress an image before it blurs. Match any article and it points to the corresponding feature page, without needing to know its name first.
Q: How often is this content updated?
It accumulates with tools and problems, with no fixed schedule. 58 articles against 101 tool pages means most features currently have no companion article, which only says nobody has written that experience up yet, not that the feature cannot do it.
Q: Can one piece belong to two categories at once?
Yes, and the boundary follows the input you are holding: errors and data go to technical notes, existing files to resource sharing, pure arithmetic to life essays. This guide sits among the 14 in resource sharing, and it is neither a problem note for one tool nor a solution to one specific job.
Q: I searched by problem and found nothing, does that mean the site has not covered it?
Most likely there is no matching record. In that case the tool page is the quicker route, since parameters and supported ranges are written there; a missing article only means a missing piece of reasoning, not a missing feature.
On your first visit to this section, pick a category from what you are holding right now. If there is an error on screen, or a piece of data you cannot read, start with technical notes, whose 31 pieces cover the most format and text problems; if what you have to deliver is a file, an image or a code, start with resource sharing and first confirm what the next step needs before coming back to set parameters; if you only want to check a number you worked out yourself, life essays are the shortest, and a few pieces are enough to judge whether a tool's conclusion can be quoted directly.