Developer tool tutorials

JSON Formatter Tutorial

JSON is easy to read when it is indented and difficult to debug when it arrives as a single compressed line. The JSON Formatter on DevUtils.uk is meant for the common moment when you copy an API response, webhook payload, log value, package configuration, or application setting and want to see the structure immediately. Paste the text into the input box and press Format. If the content is valid JSON, the output area will show nested objects and arrays with indentation, so property names, string values, numbers, booleans, and null values are easier to scan.

A useful workflow is to format first, inspect the structure, then minify only when you need a compact value for a test request or configuration field. For example, a payload such as {"user":{"id":42,"roles":["admin","editor"]},"active":true} becomes easier to review once the user object and roles array are split onto separate lines. The Minify button reverses that readability step and removes unnecessary whitespace without changing the data.

The most common JSON errors are trailing commas, single quotes, unquoted property names, comments, and copied text that includes extra log prefixes. JavaScript object syntax is not always valid JSON. If the formatter reports an error, check the character near the message, remove comments, replace single quotes with double quotes, and confirm that every opening brace or bracket has a matching closing one. Do not paste secrets or customer records into any web tool, even one designed for browser-only processing.

For a reliable review, ask three questions after formatting: does the top-level type match what the API promised, are optional fields actually present, and are numbers stored as numbers rather than quoted strings? If you are preparing an example for documentation, replace real IDs, emails, and tokens with safe sample values before copying the formatted result. This keeps the output useful while avoiding accidental disclosure.

Base64 Encoder / Decoder Tutorial

Base64 turns bytes into text characters that are easier to move through systems that expect plain text. Developers see it in HTTP Basic auth examples, small data URLs, email bodies, test fixtures, and encoded sections of tokens. In the DevUtils.uk Base64 tool, paste normal text and choose Encode to produce a Base64 string. Paste a Base64 string and choose Decode to recover readable text when the underlying data is valid text.

A simple example is the phrase Hello from DevUtils.uk. Encoding it produces a portable string that can be copied into a test payload. Decoding that string returns the original phrase. This is useful when you need to inspect a header, compare a sample from documentation, or confirm that a service encoded exactly the value you expected. For international text, the tool handles common Unicode input by converting the browser string before encoding.

The major mistake is treating Base64 as encryption. Anyone can decode it. It provides transport convenience, not secrecy. Another common issue is missing padding, line breaks from copied emails, or a value that was URL-safe Base64 rather than standard Base64. If decoding fails, remove whitespace, confirm the alphabet being used, and check whether the source system omitted padding. Never use Base64 as a password protection method, and avoid pasting credentials or private tokens unless you are working in a secure local environment that you control.

Before sharing a decoded result, read it as if it were plain text from the beginning. Many teams accidentally reveal Basic auth strings, internal hostnames, or personal data because an encoded value looked harmless. When documenting a Base64 example, create your own neutral sentence, encode it, and label it as sample data so readers do not confuse it with a real credential.

Use this tool for small text values, not large binary files or sensitive authentication material. If a decoded value looks unreadable, it may represent binary data rather than broken text. In that case, inspect it with a file-aware tool instead of repeatedly pasting it into a browser utility.

URL Encoder / Decoder Tutorial

URLs can only carry certain characters safely. Spaces, ampersands, question marks, slashes, equals signs, and non-ASCII characters may change the meaning of a query string if they are not encoded correctly. The DevUtils.uk URL tool helps you encode a value before placing it in a parameter and decode an existing value when you need to understand what a link is actually sending.

Suppose a search term is Dev Utils & private tools. If you place that directly after ?q=, the ampersand can be interpreted as the start of another parameter. Encoding turns unsafe characters into percent escapes so the whole phrase remains one value. Decoding does the reverse and is helpful when debugging redirect URLs, analytics links, webhook callback URLs, or OAuth-style query parameters.

The common mistake is encoding an entire URL when only a parameter value should be encoded. If you encode https://example.com/?q=test as one value, the slashes and question mark will be escaped too, which may be correct inside another parameter but wrong when you want a clickable URL. Another mistake is double encoding, where %20 becomes %2520. If a decoded value still contains many percent sequences, it may have been encoded more than once. Treat decoded links carefully, especially if they contain access tokens, email addresses, or return URLs.

A good debugging habit is to split the URL into path, query key, and query value before changing anything. Encode only the value unless you intentionally need to nest a full URL inside another URL. After decoding, check whether redirect targets point to trusted domains. URL encoding makes data transportable, but it does not make a destination safe or approved.

When writing documentation, show both the raw value and the encoded value so readers understand which part changed. For application code, prefer standard URL and query parameter APIs over manual string concatenation. They reduce double-encoding bugs and make edge cases easier to test.

UUID Generator Tutorial

A UUID is a widely used identifier format that is useful when you need a unique-looking value without asking a database for the next number. The DevUtils.uk UUID Generator creates random version 4 UUIDs in the browser. Use Generate one for a single test record or Generate ten when you need a small batch for fixtures, mock API responses, database seed rows, or documentation examples.

UUIDs are helpful because they avoid collisions in many practical workflows and do not reveal sequence information the way incremental IDs can. A test user ID like 8f63f0a0-4ec7-4f5e-9b9f-2b4fb8fbb999 is safer for examples than using a real customer identifier. In frontend work, UUIDs can label temporary rows before the backend assigns final IDs. In QA, they make repeated test runs easier to distinguish.

The common mistake is assuming a UUID proves that something exists or that a request is authorized. A UUID is only an identifier. Your application still needs permission checks, ownership checks, and validation. Another mistake is regenerating identifiers for records that should stay stable; if an ID is used as a key in a database, cache, or UI list, changing it can break references. Do not use random UUIDs for cryptographic secrets. They are identifiers, not API keys or passwords.

When using generated IDs in tests, store them beside the fixture that explains their purpose. A list of random-looking values becomes confusing quickly if no one knows which ID represents an admin, a deleted row, or an edge case. For production systems, decide whether UUIDs should be generated by the client, server, or database, then keep that ownership consistent.

UUIDs are also useful in written bug reports because they are easy to search and unlikely to collide with ordinary words. If you paste a generated UUID into logs or tickets, label it as sample data. That keeps teammates from wasting time looking for a record that was never meant to exist.

Timestamp Converter Tutorial

Timestamps appear in logs, APIs, databases, analytics exports, job schedulers, and audit events. The difficult part is remembering whether a value is Unix seconds, Unix milliseconds, or a formatted date string. The DevUtils.uk Timestamp Converter accepts common Unix seconds, Unix milliseconds, and parseable dates, then shows ISO time, Unix seconds, Unix milliseconds, and the browser's local display.

If you paste 1782190800, the tool treats it as Unix seconds. If you paste a thirteen-digit value such as 1782190800000, it treats it as milliseconds. ISO strings are useful when you want a timezone-explicit value for documentation or API debugging. The Use current time button is handy when creating a fresh example value for a support ticket or test request.

The most common bug is seconds versus milliseconds. A timestamp that appears thousands of years in the future was probably interpreted as seconds when it was actually milliseconds. A date near 1970 may have the opposite problem. Time zones are another frequent source of confusion: ISO strings ending in Z are UTC, while local display depends on the user's environment. When debugging production issues, record the original timestamp, the timezone, and the converted ISO value so other people can reproduce your interpretation.

For incident notes, include both the original value and an ISO UTC conversion. That prevents confusion when teammates work in different regions or when screenshots show a local timezone. If a scheduled job ran at the wrong time, also check daylight saving rules and whether the scheduler expects UTC, server local time, or an application-specific timezone setting.

When building APIs, document timestamp units explicitly in field names or schema descriptions. Names such as createdAtMs or expiresAtUnixSeconds are less elegant than createdAt, but they prevent expensive ambiguity. If you cannot rename a field, add examples to the API documentation.

SHA-256 Hash Generator Tutorial

SHA-256 creates a deterministic digest from input text. The same input produces the same hash, while even a tiny change produces a very different output. The DevUtils.uk SHA-256 tool is useful for comparing text integrity, documenting exact fixture values, checking whether two copied strings are identical, or creating stable non-secret identifiers for examples.

Paste text into the input area and choose Generate hash. The output is a hexadecimal SHA-256 digest. For example, hashing a configuration snippet before and after editing can confirm that the content changed. In documentation, a hash can identify the exact sample file or string used without repeating the whole value. In support work, hashes can help compare whether two teams are discussing the same payload.

The key mistake is confusing hashing with encryption. A hash is one-way and cannot be decoded to recover the original text, but short or predictable inputs can be guessed by hashing many candidates. Do not hash passwords manually with plain SHA-256 for production authentication; password storage requires slow, salted password hashing functions. Also remember that whitespace matters. A trailing newline, different line endings, or one extra space will create a different digest. When comparing hashes, make sure both sides use the same exact input encoding.

A practical checklist is to define what should be hashed, normalize the text if your workflow requires it, and store the hash with enough context to make it meaningful. If two hashes differ, inspect line endings, invisible spaces, character encoding, and copied punctuation before assuming the business data changed. For files, use a dedicated file hashing tool rather than pasting large content into a text box.

Hashes work best when the input boundary is clear. Decide whether the hash includes headers, whitespace, sorted keys, or only a field value. If several systems need to reproduce the same digest, write the exact rules down. Otherwise, every team may hash a slightly different string.

Color Converter Tutorial

Design and frontend work often moves between hex, RGB, and HSL color formats. A designer may hand over #0f766e, a CSS file may use rgb(), and a theme system may prefer HSL because hue, saturation, and lightness are easier to adjust. The DevUtils.uk Color Converter accepts a six-digit hex color and returns hex, RGB, and HSL values with a visible preview swatch.

Paste a value such as #0f766e and choose Convert. The RGB result is useful for CSS, canvas work, or systems that store colors as red, green, and blue channels. The HSL result is useful when you want lighter, darker, or less saturated variants while preserving the same general hue. The preview swatch is a quick visual check that the pasted value is the color you intended.

Common mistakes include using three-digit shorthand when a tool expects six digits, copying a value with hidden characters, or mixing up brand colors that look similar in isolation. Another issue is contrast: a valid color is not automatically accessible. Before using a color for text, check contrast against its background. For production design systems, store color decisions as named tokens rather than scattering raw hex values throughout many files.

When you convert a color, record where it will be used: text, border, background, chart series, alert state, or brand accent. A color that looks good in a preview square may fail in a dense table or on a mobile screen outdoors. Test important combinations in the real interface, not only in a converter, and keep fallbacks for dark mode or high-contrast themes.

If you are building a design system, avoid naming tokens after the raw color alone. Names such as action-background, warning-border, or chart-series-a communicate purpose better than teal-700. Purpose-based names make future redesigns easier because the role can stay stable while the exact color changes.

Text Diff Checker Tutorial

A text diff helps you understand what changed between two short snippets. The DevUtils.uk Text Diff Checker compares the original and changed text line by line. It is useful for reviewing environment variables, documentation edits, configuration examples, support replies, small JSON fragments, and copied command output before sharing or saving.

Paste the older version on the left and the newer version on the right, then choose Compare. Unchanged lines are shown with a leading space, removed lines with a minus sign, and added lines with a plus sign. This compact output is easy to copy into a ticket or pull request comment when the change is small enough to discuss directly.

The tool is intentionally simple. It does not replace a full version control diff for large files, moved blocks, or complex code review. The most common mistake is comparing minified or wrapped text where line breaks do not match; formatting the text first often makes the diff more useful. Another mistake is pasting private configuration secrets into a web page. Remove API keys, passwords, tokens, and customer details before comparing snippets. For serious source code review, use Git or your repository platform's built-in diff.

For support work, a clean diff can reduce back-and-forth. Include only the lines that matter and explain whether the change is an addition, removal, or replacement. If the text contains generated IDs or timestamps, decide whether those differences are meaningful before reporting them as bugs. A diff is a signal, not a final diagnosis.

Before copying a diff into a public issue or shared chat, scan it for secrets and personal data. Configuration snippets often contain endpoints, tenant names, tokens, or internal comments. Replace those values with placeholders and keep enough surrounding context for the change to remain understandable.

If the change matters enough to save, copy the final diff into the system of record, such as a ticket, pull request, or deployment note. Temporary browser output should support the review, not become the only place where the reasoning lives.

Regex Tester Tutorial

Regular expressions are powerful, but small syntax changes can completely alter what they match. The DevUtils.uk Regex Tester lets you enter a JavaScript regular expression pattern, optional flags, and sample text. It then lists matching text and the index where each match begins. This is useful before adding a pattern to validation code, log filters, search scripts, or documentation.

Start with a small sample. For example, the pattern dev\\w+ with the gi flags matches words beginning with dev regardless of case. The g flag finds multiple matches, while i makes matching case-insensitive. Testing against realistic examples is better than testing only the happy path. Add strings that should match and strings that should not match.

Common mistakes include forgetting to escape backslashes, using a pattern that is too greedy, or validating complex formats with a regex that misses real-world cases. Email addresses, URLs, and international names are classic examples where simple patterns often reject valid input or accept invalid input. Another risk is catastrophic backtracking in certain complex expressions. For production validation, keep patterns simple, measure performance on long input, and combine regex checks with clear application-level rules. Do not paste sensitive logs unless you have removed private values.

A good pattern review includes at least three examples: one that should match, one that should not match, and one edge case that is easy to overlook. If your expression will run on user input, test long strings and repeated characters. If a regex starts becoming unreadable, consider splitting the problem into simpler checks with clearer error messages.

Regex is best for recognizing patterns, not for understanding every kind of structured language. If you need to parse JSON, HTML, CSV, or programming code, use a parser designed for that format. The tester is most useful for focused checks such as log filters, simple validation, and search expressions.

JWT Inspector Tutorial

A JSON Web Token often contains a header, payload, and signature separated by dots. The DevUtils.uk JWT Inspector decodes the header and payload so you can read claims during debugging. Paste a token and choose Decode token. The output shows decoded JSON and explicitly marks that the signature is not verified.

This distinction matters. Decoding is only reading Base64URL-encoded JSON. Verification requires the correct key, algorithm rules, issuer, audience, expiration policy, and application trust decisions. The browser inspector is useful for checking whether a token contains the expected subject, issued-at time, role claim, tenant ID, or expiry claim, but it cannot tell you whether your backend should accept the token.

Common mistakes include pasting production access tokens into random tools, assuming decoded claims are trustworthy, or ignoring time-based claims such as exp, nbf, and iat. Another mistake is accepting the alg value from the token without server-side restrictions. Treat JWTs as credentials. If you need to inspect a real token, prefer a local trusted environment and remove it after debugging. Use this tool mainly for examples, development tokens, and non-sensitive troubleshooting.

When reviewing a decoded token, write down what question you are answering. Are you checking the user ID, the tenant, the scopes, or the expiry time? Avoid reading extra meaning into claims that your backend does not enforce. If a claim appears wrong, verify the issuer configuration and server clock before assuming the frontend caused the issue.

For tutorials, demos, and screenshots, create a fake token with harmless claims rather than using a real session token. Even expired tokens can reveal usernames, tenant IDs, project names, or internal authorization design. Treat token examples as documentation artifacts, not copied production evidence.

If the token includes exp, nbf, or iat, convert those timestamps before drawing conclusions. Many authentication bugs are simple clock or timezone misunderstandings. Keep the decoded view, server verification logs, and application error message together when troubleshooting.