[ { "slug": "about-us", "title": "About Us", "body": "[[site_name]] is operated by [[operator_name]], based at [[operator_address]]. Our aim is to make routine text, formatting and calculation tasks easier to complete and easier to check.\n\nWHAT THE SERVICE DOES\nThe platform provides focused tools with labelled inputs and structured results. Some operations count or transform text; others format data or demonstrate straightforward calculations. Each enabled tool should explain its purpose and limitations. Tools that have not been implemented are kept out of the public catalog.\n\nHOW WE APPROACH ACCURACY\nA successful calculation or transformation is not proof that the source material is correct. We encourage you to compare important results with the original data, retain a copy of your input and check assumptions before making a decision. We do not present simple keyword counts as a guarantee of ranking, checksums as password protection, or text formatting as a substitute for professional judgement.\n\nEDITORIAL APPROACH\nOur guides are written to explain practical workflows, common mistakes and checks you can repeat. They are not personalised legal, medical, tax or financial advice. An article may discuss an available tool without recommending that you upload confidential information. We update material when a reported problem or a product change makes a revision necessary.\n\nPRIVACY AND COMMERCIAL SUPPORT\nTool processing takes place on the server. Avoid submitting passwords, private keys, identity documents or information you are not authorised to share. Advertising and measurement features, when enabled, are described in our Privacy Policy and controlled through the site's consent options. The presence of advertising does not certify the accuracy of a tool or endorse an advertiser.\n\nCONTACT\nQuestions, accessibility requests and corrections can be sent to [[contact_email]]. Include the relevant page address and a brief description, but do not email sensitive tool input unless we agree on a suitable way to handle it.", "is_published": false, "kind": "legal", "meta_description": "About Us for the operator and users of this tool platform." }, { "slug": "contact-us", "title": "Contact Us", "body": "Contact [[operator_name]], the operator of [[site_name]], at [[contact_email]]. Our contact address is [[operator_address]].\n\nGENERAL QUESTIONS\nTell us which tool or guide you are asking about and what you expected it to do. If you are reporting an error, a short invented example is usually more useful and safer than a complete customer document. Never include passwords, payment-card details, private keys or another person's sensitive information.\n\nREPORTING A TOOL PROBLEM\nPlease include the page address, approximate time, your browser name, the visible error and steps that reproduce the problem. If the result looks inaccurate, explain which output you expected and why. We may ask for a non-confidential sample to understand the issue. We do not promise a response time or uninterrupted support availability.\n\nPRIVACY REQUESTS\nUse the subject “Privacy request” and explain whether you want information about a record, correction, deletion or another privacy matter. Provide only the minimum information needed to identify your request. We may need to verify identity before responding where a request would expose someone else's information. The records we can locate depend on what the service actually retains.\n\nSECURITY REPORTS\nUse the subject “Security report”. Describe the affected feature and a minimal, non-destructive reproduction. Do not access another person's account, extract their data, interrupt service or publish private information while demonstrating a problem. Contacting us does not authorise testing outside your own account or data.\n\nACCESSIBILITY AND CONTENT CORRECTIONS\nWe welcome reports of inaccessible controls, confusing labels and inaccurate guides. Name the page and describe the barrier or proposed correction. An alternative format can be discussed by email.", "is_published": false, "kind": "legal", "meta_description": "Contact Us for the operator and users of this tool platform." }, { "slug": "privacy-policy", "title": "Privacy Policy", "body": "This notice describes the intended operation of [[site_name]], operated by [[operator_name]] at [[operator_address]]. Privacy questions can be sent to [[contact_email]]. The operator must keep this notice consistent with the integrations and hosting services actually used.\n\nINFORMATION USED TO PROVIDE TOOLS\nWhen you submit a tool form, the service receives the submitted values, a tool identifier and essential session information. Inputs and outputs stored by the application are encrypted using the application encryption key. That encryption protects stored records; it does not mean the operator is technically unable to decrypt them. Transport protection depends on the site's HTTPS deployment.\n\nA tool result is linked to the browser session that created it. It is not intended to be a publicly indexed page. Inputs are cleared when processing completes or fails. Results expire after one hour, and the scheduled cleanup removes expired records. Because cleanup runs periodically, physical deletion may occur up to an additional hour later when the scheduler is operating normally. Backup copies may follow a separate retention schedule. Do not submit credentials, private keys or confidential material.\n\nACCOUNTS AND SECURITY\nAccounts store a name, email address, hashed password, role assignments, account status and, where enabled, encrypted two-factor authentication material. Essential cookies maintain sessions, protect forms and enforce sign-in. Administrative audit records describe actions and changed field names without intentionally including tool input or passwords. Security and infrastructure logs may contain technical request information; hosting and proxy logging must be configured consistently with this notice.\n\nOPTIONAL MEASUREMENT\nThe built-in analytics system is off by default and records page visits only after the required consent signal. It can record the page path, a daily session-derived identifier, broad device/browser classification, referrer host, traffic source and approximate country. The application does not store raw IP addresses in its visitor table. A local country lookup may temporarily use the request IP to determine a country. Daily identifiers estimate sessions; they do not identify unique people reliably. Analytics retention is configurable up to 90 days.\n\nGOOGLE, META AND ADVERTISING\nIf the operator enables Google Analytics, Meta Pixel or AdSense, the configured providers can receive information from consenting browsers. Provider requests normally reveal an IP address and browser/network details. The application does not deliberately include submitted tool text in tracking events. Third-party scripts and provider account settings must also be reviewed: enabling a provider is not a guarantee that it collects nothing beyond the application's event configuration. Google Analytics enhanced measurement, Meta automatic matching and other optional provider features should be configured consistently with the site's disclosures.\n\nCONSENT AND CHOICE\nOptional analytics and marketing are denied by default. Use Privacy preferences to change the built-in choices or Manage cookie preferences when the configured CMP is active. Do Not Track and Global Privacy Control cause this implementation to deny optional tracking. AdSense additionally requires a successful configured CMP/TCF decision. Withdrawing consent stops future loading by this implementation and reloads the page after revocation of loaded services; it does not erase data a provider already received or cookies the site cannot access.\n\nSHARING AND OPERATIONS\nHosting, delivery, consent, measurement and advertising providers may process data needed for the features the operator enables. Requests may be handled outside your country. The operator must identify its actual providers, relevant processing terms and transfer arrangements before publishing this notice. Data is not made public merely because it was processed by a tool.\n\nYOUR REQUESTS\nDepending on the applicable rules and circumstances, you may be able to request access, correction, deletion or other controls over personal information. Contact [[contact_email]] with enough information to understand the request. Do not assume that a pseudonymous visit can be linked back to a named person. We may verify identity and consider record-retention obligations before responding.\n\nCHILDREN AND SENSITIVE INFORMATION\nThis service is not designed to collect children's sensitive data. If children form part of the actual audience, the operator must review age-appropriate design, advertising and consent obligations before enabling tracking. Do not submit information about another person without appropriate authority.\n\nCHANGES\nWe may revise this notice to reflect changes in the service. The page's updated date identifies the latest published revision. Material changes to optional processing may require a new consent choice.", "is_published": false, "kind": "legal", "meta_description": "Privacy Policy for the operator and users of this tool platform." }, { "slug": "disclaimer", "title": "Disclaimer", "body": "[[site_name]] provides general-purpose information and software utilities. It is operated by [[operator_name]] and can be contacted at [[contact_email]].\n\nCHECK IMPORTANT RESULTS\nTool results depend on your inputs, assumptions and the implementation's limitations. Review important results independently before using them in a publication, contract, production system or business decision. A successful request does not certify that the source data is accurate, complete or suitable for your intended use.\n\nNO PROFESSIONAL ADVICE\nExamples and calculators are educational. They do not assess your personal circumstances and do not replace advice from a qualified professional where that advice is needed. A tax percentage field is not a determination of which tax rules apply. A loan estimate is not a lender's offer. A checksum does not establish copyright ownership, identity or the safety of a file.\n\nSEO AND PUBLISHING\nFormatting metadata or generating a robots.txt file does not guarantee search visibility, rankings, traffic, monetisation or AdSense approval. Search engines and advertising providers make their own decisions and can change their systems. Publish only claims you can support and content you have permission to use.\n\nTHIRD-PARTY CONTENT\nAdvertisements and external services may be supplied by others. Their presence is not an endorsement of a product, accuracy claim or commercial offer. Review the applicable provider's terms before using it or sharing information.\n\nAVAILABILITY AND RESPONSIBILITY\nThe service may be unavailable, changed or withdrawn. Keep your own copy of important work. Use the service only for lawful purposes and do not submit information you are not authorised to process. This disclaimer does not exclude rights or responsibilities that applicable law does not permit to be excluded.", "is_published": false, "kind": "legal", "meta_description": "Disclaimer for the operator and users of this tool platform." }, { "slug": "terms-and-conditions", "title": "Terms & Conditions", "body": "These terms concern [[site_name]], operated by [[operator_name]], [[operator_address]]. Questions can be sent to [[contact_email]]. The operator identifies [[jurisdiction]] as its relevant jurisdiction, subject to mandatory protections that may apply to a user elsewhere. These terms must be reviewed for the operator's actual business and audience before publication.\n\nUSING THE SERVICE\nUse the service only for lawful activities and within your authority. You are responsible for the content you submit and for reviewing results before using them. Keep a copy of important material: temporary tool results are not a storage or archival service. Do not submit credentials, private keys, stolen information or material you have no right to process.\n\nACCOUNTS\nKeep account credentials private and provide accurate account information. Administrators must use two-factor authentication. Tell the operator if you believe your account has been compromised. Accounts or individual tools may be restricted for misuse, security concerns or operational needs. No account role grants permission to bypass technical access controls.\n\nPROHIBITED CONDUCT\nDo not attempt unauthorised access, exploit another person's session, evade rate limits, upload malicious files, disrupt service or use the tools to infringe another person's rights. Do not represent automated or incomplete outputs as independently verified work. Security research requires an appropriate scope; simply using this site does not authorise intrusive testing.\n\nCONTENT AND RESULTS\nYou retain whatever rights you already hold in your input. Submitting material permits the processing necessary to provide the requested operation; it does not establish that the material belongs to you. You are responsible for permissions and licences associated with source material and its later use. The operator does not claim that a transformation makes copyrighted material free to republish.\n\nLIMITATIONS OF TOOLS\nTools can have errors, limits and unsupported cases. Calculations use stated assumptions and may differ from commercial systems because of fees, compounding, rounding or other rules. SEO utilities do not guarantee rankings. File and network tools should only be used on resources you are authorised to access. Disabled features are not available merely because their names appear in project documentation.\n\nSERVICE CHANGES\nThe operator may update, limit or discontinue features. We do not promise continuous availability or permanent retention of results. Any paid offering, if introduced, requires clear pricing and applicable payment/refund terms before purchase; this document does not invent a subscription arrangement.\n\nPRIVACY, ADVERTISING AND EXTERNAL SERVICES\nThe Privacy Policy describes data processing and optional integrations. External providers may have their own terms. Advertising does not constitute endorsement. Consent choices control optional features as described by the site; they do not remove essential security processing.\n\nRESPONSIBILITY AND DISPUTES\nReview outputs independently and take reasonable steps to protect your own data. Nothing here removes mandatory consumer or other legal rights. Any liability limits, dispute procedure or governing-law clause must be appropriate to the actual operator and reviewed before use rather than inferred from a generic template.\n\nCHANGES TO THESE TERMS\nThe operator may publish updated terms when the service changes. The displayed updated date identifies the published revision. Continued use should be assessed under the terms actually applicable at the relevant time.", "is_published": false, "kind": "legal", "meta_description": "Terms & Conditions for the operator and users of this tool platform." }, { "slug": "word-count-before-submission", "title": "How to check a word limit before submitting your work", "body": "A word limit sounds precise until two programs produce different totals. One may count a hyphenated expression as one word; another may split it. Footnotes, captions and references may be included in one total and excluded from another. The useful question is therefore not simply “How many words are here?” It is “Which counting rule will the person receiving this work use?”\n\nSTART WITH THE REQUIREMENT\nRead the assignment, submission portal or publication guidance. Note whether the title, abstract, quotations, tables, citations and reference list count. If the requirement is unclear, record your assumption instead of pretending that a counter can resolve it. A counter measures text according to its implementation; it cannot interpret an institution's unpublished policy.\n\nPREPARE A COUNTABLE COPY\nKeep your original document unchanged. Make a separate copy containing only the sections that should count. Avoid silently deleting a caption that explains an important figure merely to reduce the total. If a section is excluded from the formal limit, exclude it consistently from every comparison you make.\n\nUNDERSTAND THIS TOOL\nThe word counter in this platform separates text at whitespace. That is a simple, reproducible method, but it is not a full linguistic segmentation system. It works differently from language-aware tools for scripts that do not normally place spaces between words. Punctuation attached to a word remains part of the same whitespace-delimited item. An empty-looking field containing unusual separators may also need inspection.\n\nCOMPARE BEFORE EDITING\nPaste a short representative sample containing headings, numbers and punctuation into your document editor and this tool. If the totals differ, examine the sample instead of averaging the results. Averaging incompatible counting rules does not create a correct answer. Prefer the method specified by the receiving organisation and keep a modest margin below a strict limit.\n\nREDUCE WORDS WITHOUT REMOVING MEANING\nCut repeated claims, unnecessary introductions and phrases that do not change the sentence's meaning. Replace a vague statement followed by several clarifications with one precise statement. Preserve qualifications that affect accuracy: changing “may increase” to “increases” saves a word but changes the claim. Keep evidence and attribution when they are needed to support an argument.\n\nFINAL CHECK\nCount the actual file you will submit, not an earlier draft. Confirm that the last revision has not restored excluded notes or duplicated a paragraph. Save the final version with a clear name and retain any guidance that explains what was included. For assessed work, the institution's rule matters more than a third-party counter's label.", "is_published": true, "kind": "guide", "meta_description": "A word limit sounds precise until two programs produce different totals. One may count a hyphenated expression as one word; another may split it. Footnotes, captions and references may be included in one total and excluded from another. The useful question is therefore not simply" }, { "slug": "characters-unicode-and-bytes", "title": "Characters, Unicode and bytes: which length do you need?", "body": "Text has several kinds of length. The word “café” may look like four letters, but its byte count depends on encoding and on how the accented character is represented. An emoji can appear as one symbol while containing several Unicode code points. A limit expressed as “characters” therefore needs an exact definition before you can enforce it reliably.\n\nVISIBLE SYMBOLS ARE NOT ALWAYS CODE POINTS\nThe character counter here uses PHP's multibyte string length for UTF-8 text. It is closer to a code-point count than a count of the symbols a reader perceives. Combining marks and emoji sequences can make those quantities differ. Do not describe the output as a universal count of visible letters.\n\nBYTES ANSWER A DIFFERENT QUESTION\nByte length describes how much encoded data a string contains. It is useful when checking a transport or storage limit, but it is not a measure of how much someone has written. An English sentence and a Bengali sentence with similar visible lengths may occupy different numbers of bytes. This is normal for UTF-8 rather than evidence that one text is corrupted.\n\nWHITESPACE NEEDS A RULE\nA “without whitespace” count removes recognised spaces and separators; it does not necessarily remove every invisible Unicode character. Copying from a PDF or website can introduce non-breaking spaces or other characters that are hard to see. If a field rejects text that appears short enough, inspect the actual content instead of repeatedly deleting visible letters.\n\nDESIGNING A FORM\nChoose a limit that matches the downstream system. A database constraint, an API byte limit and a user-facing character allowance should not be treated as interchangeable. Validate on the server as well as in the interface. Browser controls can improve the experience but cannot replace server validation.\n\nTEST A REPRESENTATIVE SAMPLE\nUse examples containing accented letters, Bengali text, an emoji, a newline and a pasted non-breaking space. Compare the application's displayed count with the service that will receive the text. If your use case needs user-perceived characters, use a grapheme-aware method and document that choice.\n\nKEEP THE ORIGINAL\nNormalising Unicode can make comparisons more consistent, but it is a deliberate transformation. Do not normalise identifiers, signed content or legal evidence without understanding the consequences. Save the source text, record the chosen counting method and test edge cases before building a rule around a number.", "is_published": true, "kind": "guide", "meta_description": "Text has several kinds of length. The word “café” may look like four letters, but its byte count depends on encoding and on how the accented character is represented. An emoji can appear as one symbol while containing several Unicode code points. A limit expressed as “characters”" }, { "slug": "json-formatting-without-data-loss", "title": "Format JSON without confusing formatting with validation", "body": "Pretty-printing JSON makes it easier to read, but readability and correctness are separate questions. A formatter can reveal indentation and nesting. It cannot establish that a field has the right business meaning, that a number is the right unit or that the document matches the receiving API's contract.\n\nSTART WITH VALID JSON\nJSON uses double-quoted strings, defined literal values and a specific object/array syntax. Comments, trailing commas and single-quoted keys that are accepted in some programming languages are not standard JSON. If a document fails to parse, inspect the first reported location and nearby punctuation. A missing quote earlier in the file can make a later line appear to be the problem.\n\nOBJECTS AND ARRAYS ARE DIFFERENT\nAn empty object and an empty array carry different information. They should not be interchanged merely because both look empty. This platform decodes JSON into objects when formatting so that an empty object remains an object on output. Test that behaviour when moving data between languages and libraries.\n\nWATCH LARGE NUMBERS\nA JSON number can exceed a programming language's exact integer range. Formatting through a parser can therefore affect numeric precision in some environments. Use string representations for identifiers that are not quantities, such as long account references, when the API contract allows it. Do not run financial ledgers or cryptographic payloads through an unfamiliar formatter and assume byte-for-byte equivalence.\n\nDUPLICATE KEYS DESERVE ATTENTION\nA document containing the same object key more than once is ambiguous to many workflows. Parsers may retain only one occurrence. A successful parse is not proof that the original had no duplicate keys. If duplicate-key detection matters, use a validator that explicitly reports it before reserialising the document.\n\nCHECK THE CONTRACT\nAfter formatting, validate required fields, types, allowed values and nesting against the intended schema or API documentation. Distinguish a missing field from an explicit null. Confirm whether an empty array is valid and whether extra fields are rejected or ignored. These checks are separate from adding indentation.\n\nHANDLE SECRETS LOCALLY\nAPI tokens, private keys and personal records should not be pasted into a public formatter. Use an invented sample or a trusted local tool. Keep the original when exact bytes matter: signing, hashing and some comparison workflows are sensitive to whitespace and key order even when two JSON documents describe similar data.", "is_published": true, "kind": "guide", "meta_description": "Pretty-printing JSON makes it easier to read, but readability and correctness are separate questions. A formatter can reveal indentation and nesting. It cannot establish that a field has the right business meaning, that a number is the right unit or that the document matches the " }, { "slug": "base64-is-not-encryption", "title": "Base64 is an encoding, not a privacy control", "body": "Base64 represents bytes using a restricted set of printable characters. It helps move data through systems that expect text. It does not hide a secret: anyone who has the encoded value can decode it without a password or private key.\n\nWHY ENCODING EXISTS\nSome protocols and file formats need a text representation of binary data. Encoding creates that representation; decoding reverses it. The visible result can look unfamiliar, which sometimes leads people to mistake it for encryption. Appearance is not a security property.\n\nCHECK THE VARIANT\nStandard Base64 and URL-safe variants use different characters in some positions. Padding conventions can also vary. A decoder that accepts one form may reject another. Read the format requirement instead of deleting characters until the decoder stops complaining. A token may also contain multiple encoded sections with meaning beyond Base64 itself.\n\nTEXT AND BINARY OUTPUT\nThe decoder on this site accepts Base64 that decodes to UTF-8 text. It deliberately rejects binary output rather than presenting unreadable bytes as a usable document. A valid image or archive encoded in Base64 is therefore outside this text decoder's supported output. Use a suitable file-aware tool in a trusted environment for binary work.\n\nVALIDITY IS NOT TRUST\nA string can be correctly encoded and still contain malicious or misleading content. Decoding a value does not make its contents safe to execute, import or open. Treat decoded material with the same caution as any other untrusted input. Never pipe an unfamiliar decoded command directly into a shell.\n\nSIZE AND DATA FLOW\nBase64 usually makes data larger than the original bytes. Check request limits when an API uses encoded attachments. Encoding also does not remove personal information from a log: a token or address remains recoverable. Avoid logging secrets in encoded form under the mistaken belief that this anonymises them.\n\nA SAFE PRACTICE EXERCISE\nEncode a harmless sentence, decode the result and compare it with the original. Then alter one character and observe whether the decoder rejects it or produces different text. This demonstrates why round-trip behaviour and error detection are useful but not equivalent to confidentiality or authenticity. Protect sensitive content with appropriate security mechanisms, not with obscurity.", "is_published": true, "kind": "guide", "meta_description": "Base64 represents bytes using a restricted set of printable characters. It helps move data through systems that expect text. It does not hide a secret: anyone who has the encoded value can decode it without a password or private key." }, { "slug": "checksum-versus-password-hashing", "title": "Checksums and password hashing solve different problems", "body": "A hash maps input data to a fixed-size output. That short description covers several very different uses, so the purpose matters more than the word “hash”. Comparing a download with a trusted checksum and storing a user's password are not interchangeable tasks.\n\nCHECKING FOR A CHANGE\nA cryptographic checksum can help detect whether a file differs from an expected version. Compute the checksum using the stated algorithm and compare the entire value. A match is useful only if the expected checksum came from a trustworthy source. An attacker who can replace both the file and its advertised checksum can make a comparison look successful.\n\nEXACT INPUT MATTERS\nHashes operate on bytes. A newline at the end, a different encoding or a changed character creates a different input. When comparing text hashes, establish precisely what is being hashed. Do not assume that two strings with the same visible appearance have identical underlying representation.\n\nLEGACY ALGORITHMS\nThis tool labels MD5 as a legacy checksum. Its presence is for compatibility with workflows that still name it, not a recommendation to use it for a new security design. Do not interpret a familiar-looking short hash as evidence that a file is authentic or that collisions are impossible.\n\nPASSWORD STORAGE\nPasswords have a special threat model: people often choose predictable values, and an attacker with a stolen database can try guesses repeatedly. Password hashing systems use salts and deliberate computational cost to make those guesses more expensive. A fast general-purpose digest is not a suitable replacement for a dedicated password-hashing function.\n\nNEVER PASTE REAL PASSWORDS HERE\nA public hash generator is not a safe place to prepare production password records. Sending a password to a server introduces exposure before any hash is calculated. Use the authentication framework's supported password API inside the actual application. This platform uses a dedicated password-hashing configuration for accounts rather than its public checksum tool.\n\nRECORD YOUR METHOD\nWhen documenting a checksum, include the algorithm, the exact artefact and the source of the expected value. For security-sensitive verification, use a workflow that also addresses authenticity, such as a trusted signature process. A checksum is one component of a process, not a universal safety certificate.", "is_published": true, "kind": "guide", "meta_description": "A hash maps input data to a fixed-size output. That short description covers several very different uses, so the purpose matters more than the word “hash”. Comparing a download with a trusted checksum and storing a user's password are not interchangeable tasks." }, { "slug": "url-encoding-components", "title": "Encode the URL component you actually mean", "body": "A URL combines several components: scheme, host, path, query and sometimes a fragment. Some characters separate those components. Others are data inside them. Encoding every character in a complete address as though it were one value usually produces a result different from what you intended.\n\nCOMPONENTS BEFORE CONVERSION\nIf you are placing a search phrase inside a query parameter, encode that phrase as a parameter value. Do not encode the surrounding scheme, host and separators with the same operation. Similarly, constructing a path segment is different from constructing an entire path with intentional slashes.\n\nPERCENT ENCODING\nPercent encoding represents bytes using a percent sign and hexadecimal digits. Unicode text may require several encoded bytes for one visible character. Decoding reverses that representation, but it does not validate that the resulting address is safe to fetch or appropriate for your application.\n\nSPACES AND PLUS SIGNS\nSome form-encoding conventions represent a space with a plus sign. Raw percent encoding commonly uses %20. The URL encoder here uses raw URL encoding, and its matching decoder does not treat every plus sign as a space. Match the encoder to the protocol instead of assuming that all URL-related tools implement the same convention.\n\nAVOID DOUBLE ENCODING\nRepeatedly encoding a value can turn the percent signs from an earlier pass into new encoded sequences. The result may still look valid but mean something different to the receiving service. Track whether a value is raw or already encoded and encode at the final boundary where the contract requires it.\n\nDECODING IS NOT AUTHORISATION\nA decoded URL might point to a private server, a privileged endpoint or an untrusted domain. Validation of the syntax alone does not prevent server-side request forgery. Applications that fetch user-supplied URLs need separate network restrictions, redirect checks and resource limits.\n\nTEST WITH EXAMPLES\nTry a phrase containing spaces, an ampersand, a plus sign and non-ASCII text. Place the encoded value in a sample parameter and check how the receiving system interprets it. Avoid putting credentials or personal information into query strings: browser history, logs, referrers and analytics can expose them even when they are percent-encoded.", "is_published": true, "kind": "guide", "meta_description": "A URL combines several components: scheme, host, path, query and sometimes a fragment. Some characters separate those components. Others are data inside them. Encoding every character in a complete address as though it were one value usually produces a result different from what " }, { "slug": "write-useful-meta-descriptions", "title": "Write metadata that describes the page honestly", "body": "A page title and meta description help describe a page to people and systems. They are not a place to promise a result the page cannot deliver. Useful metadata starts with a clear understanding of the page's actual task, audience and content.\n\nONE PAGE, ONE MAIN PURPOSE\nName the specific tool or topic. A generic title such as “Best Free Online Tools” repeated across every page makes it difficult to distinguish one result from another. A title should make sense on its own while remaining consistent with the visible heading and content.\n\nDESCRIBE THE ACTION\nA useful description explains what the visitor can do, what input is needed and any limitation that materially changes the decision to use the page. For example, a decoder that only returns UTF-8 text should not imply that it handles every binary attachment. Accuracy matters more than adding impressive adjectives.\n\nLENGTH IS A DESIGN CONSTRAINT\nInterfaces display different amounts of text, and search systems may rewrite or truncate snippets. Treat character limits as practical writing guidance rather than a guarantee of exactly what will appear. Put the most useful information early and avoid a description that becomes misleading when shortened.\n\nDO NOT STUFF KEYWORDS\nRepeating a phrase in several forms usually makes a description harder to read. Use the language a person would use to identify the task. A description is not a substitute for substantial, helpful page content, and it cannot guarantee rankings or traffic.\n\nESCAPE GENERATED MARKUP\nWhen generating a title or meta element programmatically, escape quotes and angle brackets correctly. A user-supplied title must remain text rather than becoming executable markup. This site's generator escapes values and displays the result for review; inspect the destination template as well before deployment.\n\nREVIEW AFTER CHANGES\nMetadata becomes stale when a page's behaviour changes. If a tool switches from local processing to a remote provider, or adds an account requirement, review the description and instructions. Search Console can help inspect how a real site is discovered, but adding a verification token does not itself fix indexing or content quality. Keep a record of which page was changed and why.", "is_published": true, "kind": "guide", "meta_description": "A page title and meta description help describe a page to people and systems. They are not a place to promise a result the page cannot deliver. Useful metadata starts with a clear understanding of the page's actual task, audience and content." }, { "slug": "robots-is-not-access-control", "title": "Robots.txt is not a password or a privacy barrier", "body": "A robots.txt file communicates crawling preferences to automated clients that choose to follow them. It is not an authentication system. Listing a private path there does not prevent a browser, a script or an uncooperative crawler from requesting it.\n\nSEPARATE THREE QUESTIONS\nAsk whether a resource may be accessed, whether it should be crawled and whether it should appear in a search index. Access control belongs in the application and server. Crawling preferences belong in the robots protocol. Indexing instructions require the relevant page or response controls and do not replace access restrictions.\n\nPROTECT PRIVATE RESULTS\nA temporary tool-result page should verify that the requesting session owns the result, reject expired records and avoid shared caching. A noindex header provides an additional publishing signal, but it does not make an exposed result private. This platform combines session checks, expiration and no-store responses for results.\n\nCHECK THE ENVIRONMENT\nA staging site's robots policy may intentionally disallow everything. Accidentally carrying that policy to production can interfere with discovery. The reverse mistake is also possible: treating a robots file as sufficient protection for a staging environment containing real customer data. Staging access should be restricted independently.\n\nGENERATE, THEN INSPECT\nA generator can create a starting file, but you should inspect the final file served at the actual domain. Confirm that the sitemap address uses the correct scheme and hostname. Check for duplicate or contradictory rule groups after deployment tools or plugins append their own text.\n\nDO NOT ADVERTISE SECRETS\nPaths in robots.txt are publicly visible. Do not place secrets or sensitive identifiers in those paths, and do not assume that a Disallow line hides them. A resource that needs privacy should remain protected even if its URL is known.\n\nA PRACTICAL RELEASE CHECK\nRequest a public page, an admin route and a private result from a separate session. Confirm that each receives the intended access response and headers. Then inspect robots.txt and the sitemap separately. This sequence makes it harder to confuse a search-engine preference with an actual security boundary.", "is_published": true, "kind": "guide", "meta_description": "A robots.txt file communicates crawling preferences to automated clients that choose to follow them. It is not an authentication system. Listing a private path there does not prevent a browser, a script or an uncooperative crawler from requesting it." }, { "slug": "xml-sitemaps-and-canonical-pages", "title": "Build a sitemap around pages worth discovering", "body": "A sitemap is a list of URLs you want a crawler to discover. It is most useful when those URLs reflect the site's real public structure. Filling it with disabled tools, temporary results or duplicate search pages creates noise and can conceal more important publishing mistakes.\n\nCHOOSE CANONICAL PUBLIC URLS\nInclude the preferred version of each public page. Use the intended HTTPS hostname consistently. Do not mix several hostnames or URL styles merely because they all happen to respond. If a page has moved permanently, update internal links and its sitemap entry as well as adding an appropriate redirect.\n\nEXCLUDE PRIVATE AND EMPTY PAGES\nLogin screens, admin tools and session-bound results do not belong in a public content sitemap. Neither do tool placeholders that have no functioning implementation or useful instructions. In this platform, disabled tools are excluded and unpublished pages do not receive entries.\n\nUSE MODIFICATION DATES HONESTLY\nA last-modified value should describe a meaningful change to the page. Rewriting every timestamp on every deployment can make the data less useful. Changing a global asset does not necessarily mean every article has been substantively revised. Keep content updates distinct from operational releases when practical.\n\nCANONICAL TAGS NEED CONSISTENCY\nA canonical link identifies a preferred URL, but it is not a universal command that fixes every duplicate. Internal links, redirects, sitemap entries and actual page content should support the same structure. Search and filter URLs often need a deliberate indexing policy rather than automatic inclusion.\n\nCHECK THE SERVED FILE\nInspect the live sitemap, not only the template that generates it. Verify the response type and ensure that XML special characters are escaped. Open a sample of listed URLs and confirm that they resolve as intended without requiring a session or producing an error.\n\nMEASURE THE RIGHT THING\nSubmitting a sitemap does not guarantee indexing. If important pages are missing from search, investigate access, indexing directives, canonical signals, content quality and the site's actual discovery paths. A sitemap supports a healthy publishing system; it cannot compensate for a page that is empty, misleading or inaccessible.", "is_published": true, "kind": "guide", "meta_description": "A sitemap is a list of URLs you want a crawler to discover. It is most useful when those URLs reflect the site's real public structure. Filling it with disabled tools, temporary results or duplicate search pages creates noise and can conceal more important publishing mistakes." }, { "slug": "keyword-density-with-context", "title": "Use keyword counts to inspect writing, not to chase a score", "body": "Keyword density is a ratio: how often a word appears compared with a chosen total. It can reveal repetition, but it does not measure whether an article answers a question, whether its claims are correct or whether readers understand it. Treat the count as a clue rather than an editorial verdict.\n\nDEFINE WHAT IS COUNTED\nDifferent tools split words differently, remove different punctuation and treat capitalisation in different ways. This implementation lowercases text and extracts letter/number sequences, then reports the most frequent items. It does not understand every phrase, synonym, grammatical relationship or language-specific boundary.\n\nLOOK AT THE SURROUNDING SENTENCES\nA frequently repeated word may be the subject of the article, a common grammatical word or a sign of avoidable repetition. Read the paragraphs where it occurs before changing anything. Replacing a necessary technical term with a vague synonym can make the text less precise even if the percentage falls.\n\nDO NOT INVENT A MAGIC TARGET\nThere is no percentage in this tool that certifies search quality. Adding a phrase until a meter reaches a target can make writing unnatural. The more useful question is whether the page covers the visitor's task clearly and includes the evidence or examples needed to support its explanation.\n\nCOMPARE LIKE WITH LIKE\nA short product description and a long tutorial have different structures. So do a transcript and a polished essay. Comparing their percentages without considering genre can lead to poor decisions. If you compare revisions, use the same included sections and the same counting method.\n\nUSE THE RESULT AS AN EDITING PROMPT\nIdentify an unexpectedly dominant word, inspect its contexts and ask whether the repetition is useful. Sometimes the solution is to combine sentences or improve the structure rather than substitute individual words. Keep necessary attribution and qualifications when editing.\n\nFINAL HUMAN REVIEW\nRead the revised text aloud or ask a reader unfamiliar with the draft to explain its main point. Check facts, examples and transitions. A lower repetition score is not progress if the article becomes harder to follow. Use quantitative tools to support editorial judgement, not to replace it.", "is_published": true, "kind": "guide", "meta_description": "Keyword density is a ratio: how often a word appears compared with a chosen total. It can reveal repetition, but it does not measure whether an article answers a question, whether its claims are correct or whether readers understand it. Treat the count as a clue rather than an ed" }, { "slug": "percentage-calculations-baselines", "title": "Percentages need a clearly named baseline", "body": "A percentage expresses a quantity relative to one hundred units of a chosen baseline. The arithmetic can be simple while the wording is ambiguous. Before calculating, name the original amount, the comparison amount and the question you are actually trying to answer.\n\nPERCENT OF AN AMOUNT\nTo find a percentage of a value, multiply the value by the percentage and divide by one hundred. For example, 12.5 percent of 200 is 25. This is the operation performed by the percentage tool. It is different from calculating a percentage change between two values.\n\nPERCENTAGE CHANGE\nA change normally compares the difference with the original value. If a quantity rises from 80 to 100, the increase is 20 relative to 80, or 25 percent. The difference is not 20 percent merely because the numerical difference is 20. If the original value is zero, the usual percentage-change formula requires special treatment rather than division by zero.\n\nPERCENTAGE POINTS\nWhen comparing two percentages, distinguish a percentage-point difference from a relative percentage change. Moving from 10 percent to 15 percent is an increase of five percentage points. The relative increase in that percentage is 50 percent. Both statements can be correct, but they answer different questions.\n\nREVERSE A CHANGE CAREFULLY\nA 20 percent increase followed by a 20 percent decrease does not generally return a value to its starting point, because the second operation uses a different baseline. Write each intermediate amount down when checking a multi-step calculation. Do not combine percentage adjustments by intuition alone.\n\nROUND AT THE RIGHT STAGE\nRepeatedly rounding intermediate values can change a final result. Keep sufficient precision while calculating and apply the required rounding convention at the agreed stage. For invoices, taxes or regulated reporting, use the rules required by the relevant system rather than assuming that a generic calculator knows them.\n\nLABEL THE RESULT\nA useful answer includes the amount, unit, baseline and interpretation. “25” by itself may be mathematically correct but operationally confusing. Record what was entered and avoid using an educational calculator as a substitute for a reviewed financial or accounting process.", "is_published": true, "kind": "guide", "meta_description": "A percentage expresses a quantity relative to one hundred units of a chosen baseline. The arithmetic can be simple while the wording is ambiguous. Before calculating, name the original amount, the comparison amount and the question you are actually trying to answer." }, { "slug": "emi-calculator-assumptions", "title": "What a loan payment estimate includes—and what it leaves out", "body": "A loan payment calculator turns assumptions into an estimate. The estimate is useful only when those assumptions match the actual arrangement. It should not be mistaken for an approval, a quotation or a statement of the total cost offered by a lender.\n\nNAME THE INPUTS\nThe principal is the amount being financed under the model. The annual rate is converted into a monthly rate, and the term is expressed as a number of monthly payments. This platform's example calculator assumes a fixed rate and equal payments over that term. It does not negotiate fees or inspect a contract.\n\nTHE ZERO-INTEREST CASE\nWhen the rate is zero, the principal is divided by the number of payments. A separate branch avoids applying a formula that would otherwise involve a problematic zero-rate expression. This is a useful test case when checking the implementation of a payment calculator.\n\nFEES CAN CHANGE THE COMPARISON\nAn arrangement can include setup charges, insurance, service fees or other costs that are not represented by a simple interest-rate input. A quoted rate and an overall borrowing-cost measure may also be defined differently. Do not compare two offers using only one field without understanding what each figure includes.\n\nTIMING MATTERS\nPayment frequency, the date of the first payment, interest-accrual rules, variable rates and irregular payments can affect the actual schedule. A model based on equal monthly periods may not reproduce a lender's day-by-day calculation. Small rounding differences can also accumulate across a schedule.\n\nREAD THE OUTPUT AS A MODEL\nThe monthly amount, total payment and estimated interest are related outputs from the same assumptions. They are not three independent confirmations of accuracy. Check the principal, rate and term first if an output looks surprising. A decimal-place error in the rate can matter far more than the final rounding.\n\nUSE A REAL OFFER FOR A REAL DECISION\nAsk the lender for the full payment schedule and cost disclosure relevant to the actual product. Consider affordability and uncertainty using appropriate advice where needed. This guide explains a mathematical model; it does not recommend borrowing, choosing a lender or taking a particular financial action.", "is_published": true, "kind": "guide", "meta_description": "A loan payment calculator turns assumptions into an estimate. The estimate is useful only when those assumptions match the actual arrangement. It should not be mistaken for an approval, a quotation or a statement of the total cost offered by a lender." }, { "slug": "clean-text-with-safe-pipelines", "title": "Build repeatable text-cleaning workflows", "body": "A text-cleaning task often involves several small operations: trimming extra space, normalising case, removing repeated lines or applying a literal replacement. A repeatable pipeline records those operations in an explicit order so that you can inspect and reproduce the transformation.\n\nSAVE THE ORIGINAL FIRST\nCleaning changes data. Before running a pipeline, keep an unchanged source copy and identify which features must be preserved. Capitalisation, spacing and duplicate lines may carry meaning in a legal quotation, a programming example or a list of identifiers. “Cleaner” is not automatically “more correct”.\n\nORDER CHANGES THE RESULT\nLowercasing before duplicate removal can merge lines that were previously distinct. Removing tags before a literal replacement can remove the text you meant to match. Write the intended sequence down and try it on a small example containing the edge cases you expect.\n\nAPPROVED OPERATIONS\nThe configurable processor here supports a bounded list of deterministic operations. It does not accept PHP, shell commands or arbitrary regular expressions. Administrators can compose supported steps without deploying new code, but they cannot introduce a completely new algorithm simply by giving it a name.\n\nLITERAL REPLACEMENT\nA literal replacement searches for exact text. It is useful for predictable cleanup, but it does not understand grammar or context. Replacing a short fragment can unintentionally alter larger words. Inspect representative matches and prefer a sufficiently specific search string.\n\nWATCH EXPANSION\nA replacement can make text much larger. Repeating an expanding replacement across several stages can magnify that effect. This implementation limits the number of steps and the permitted output size. If a request exceeds those bounds, reduce the input or revise the workflow rather than attempting to bypass the limit.\n\nREVIEW A DIFF\nCompare the transformed result with the original, especially at the start and end of lines and around special characters. Count removed items when deduplicating. Keep the configuration with the processed output when reproducibility matters. A pipeline should make changes more explainable, not hide them behind a button.", "is_published": true, "kind": "guide", "meta_description": "A text-cleaning task often involves several small operations: trimming extra space, normalising case, removing repeated lines or applying a literal replacement. A repeatable pipeline records those operations in an explicit order so that you can inspect and reproduce the transform" }, { "slug": "privacy-before-pasting-text", "title": "A privacy check before using any online text tool", "body": "The easiest way to avoid exposing confidential information is not to submit it to a service that does not need it. Before pasting text into an online utility, pause long enough to identify what the material contains and what the tool needs to complete the task.\n\nCLASSIFY THE MATERIAL\nLook for names, addresses, contact details, customer records, financial information, passwords, tokens and private keys. A document can reveal personal information indirectly even after obvious names are removed. A unique job title or detailed incident description may still identify someone.\n\nUSE A MINIMAL SAMPLE\nWhen testing formatting or debugging an error, an invented example often works as well as the original record. Preserve the structure that triggers the problem while changing unnecessary values. Avoid treating a simple find-and-replace of names as a guarantee of anonymisation.\n\nUNDERSTAND WHERE PROCESSING HAPPENS\nA tool that runs entirely in your browser has a different data flow from one that submits input to a server or another provider. Read the current description instead of assuming that every “online tool” operates in the same way. This platform's implemented tools submit input for server processing.\n\nREAD RETENTION CLAIMS CAREFULLY\nAn expiry time controls when a result is available, while physical deletion can depend on a scheduled cleanup. Backups and operational logs may have separate lifetimes. Encryption protects stored data under particular conditions; it does not automatically prevent the operator from accessing plaintext while providing the service.\n\nSEPARATE TOOL USE FROM TRACKING\nAnalytics or advertising scripts can have their own data flows. Consent controls are valuable, but they do not turn a public website into an appropriate place for secrets. Use a trusted local workflow when the task involves confidential material or a requirement that data not leave a controlled environment.\n\nAFTER THE TASK\nDownload or copy only the result you actually need and store it in the right location. Do not share a screenshot that contains hidden identifiers or another person's details. If sensitive information was submitted accidentally, follow your organisation's incident process and contact the relevant service with a minimal description of what happened.", "is_published": true, "kind": "guide", "meta_description": "The easiest way to avoid exposing confidential information is not to submit it to a service that does not need it. Before pasting text into an online utility, pause long enough to identify what the material contains and what the tool needs to complete the task." }, { "slug": "check-a-tool-result-systematically", "title": "How to verify a tool result with small test cases", "body": "A tool can produce a polished result and still be wrong for a particular input. Verification becomes easier when you begin with small cases whose outcomes you can predict, then add complexity deliberately. This approach is useful for both users and the developers who maintain the tool.\n\nSTART WITH A KNOWN ANSWER\nFor a percentage calculator, choose a simple amount and rate that you can calculate mentally. For a formatter, use a small object with one nested value. For a counter, begin with a short sentence whose segmentation is unambiguous. The purpose is to establish a baseline before testing harder cases.\n\nCHECK BOUNDARIES\nTry the smallest supported value, a typical value and a value near the documented limit. Consider empty input, whitespace, Unicode and invalid syntax where relevant. A rejected input is not necessarily a bug: clear rejection can be safer than quietly inventing a result.\n\nUSE ROUND TRIPS APPROPRIATELY\nEncoding followed by decoding should usually reproduce supported source data. That is a useful check for an encoder/decoder pair, but it does not prove confidentiality or safety. Some transformations are intentionally irreversible, such as hashing or lowercasing. Do not expect a round trip where the operation discards information.\n\nTEST AN INVARIANT\nAn invariant is a property that should remain true. Sorting should not silently remove lines. A duplicate-line remover should not add new unique lines. A zero-interest payment schedule should divide the principal consistently across the chosen number of payments. These relationships can reveal errors that a single expected value misses.\n\nCOMPARE INDEPENDENTLY\nTwo tools may share an implementation or the same incorrect assumption. Agreement is useful, but it is not conclusive. Compare with a hand calculation, a documented specification or a genuinely independent implementation when the result matters. Keep a record of the exact inputs and versions used.\n\nREPORT A REPRODUCIBLE PROBLEM\nA good report states the input, expected result, actual result and relevant context without including secrets. Reduce a large failure to a small example if possible. This helps distinguish an unsupported case from a defect and gives the maintainer a concrete regression test. Verification is a process, not a badge attached to a tool forever.", "is_published": true, "kind": "guide", "meta_description": "A tool can produce a polished result and still be wrong for a particular input. Verification becomes easier when you begin with small cases whose outcomes you can predict, then add complexity deliberately. This approach is useful for both users and the developers who maintain the" } ]