Frequently asked questions

Splitting is how the tool reads your input - it needs to know where one item ends. Joining is how it writes the output. They are set separately, which is what makes conversion possible: split on line breaks, join with commas, and a vertical list becomes a comma-separated string.

The main Characters figure includes them, because that is what almost every platform counts against its limit. The second figure excludes them, which is the convention for translation and typesetting work. Both are shown at once so you do not have to choose.

Articles, short conjunctions and short prepositions: a, an, and, as, at, but, by, for, in, nor, of, on, or, the, to, up, with. The first and last words are always capitalised regardless. Style guides differ on the exact list, so compare the output against your house style if you have one.

The first one. Everything after it is discarded, and the surviving line stays in its original position. If your list is ordered by relevance, date or priority, that ordering is preserved exactly.

Because it is not plain ASCII. The original standard only defines 0 to 127. Anything beyond that - accented letters, curly quotes, CJK characters, emoji - is Unicode, and the tool returns the real code point rather than failing. é is 233 and 中 is 20013.

Reverse word order changes the sequence but leaves the spelling alone: the quick fox becomes fox quick the. Reverse each word keeps the sequence but flips the spelling: eht kciuq xof. The first is a sentence read backwards, the second is the same sentence with every word scrambled in place.

Five causes account for almost everything: a trailing comma after the final item, single quotes instead of double, an unquoted key, a comment, or an unescaped control character in a string. The last two surprise people most - JSON permits no comments at all, and unlike JavaScript it rejects trailing commas.

No, and treating it as one is a real security mistake. It is a reversible encoding with no key and no secret - anyone can decode it in seconds, including this page. Use it for safe transport of data, never for keeping anything private.

Not here. Script blocks are set aside before minification and restored untouched afterwards. This matters because removing line breaks inside JavaScript comments out everything following a // on that line - a classic way that naive minifiers destroy a page.

It should not. Only characters with no meaning are removed - whitespace, comments, redundant units and equivalent colour shorthands. Source order and specificity are untouched, so the cascade resolves exactly as before.

Because this one does not rename anything. Aggressive minifiers get their headline figures by shortening every identifier to a letter or two, which is where most of their saving comes from. Skipping that costs size and buys certainty that nothing breaks.

In theory yes, in practice no. With 122 random bits you would need to generate around 2.7 quintillion values before reaching a 50% chance of a single collision. For any realistic application the risk is far smaller than the chance of a hardware failure corrupting the data anyway.

Hyphens. Google treats a hyphen as a word separator and an underscore as a joining character, so seo_meta_tags is read as one token while seo-meta-tags is read as three words. Underscores are fine in code, not in URLs.

Component mode when you are encoding one value that will sit inside a URL - a search term, a redirect target, a name. Full URL mode when you already have a complete address and just need to make it valid. The test: if the text contains slashes that are meant to stay slashes, use full URL mode.

It is an encoded percent sign, which almost always means the URL was encoded twice. %2520 is a space that has been through the process two times. Turn on repeat decoding to unwrap it fully.

Requests to private and internal addresses are refused deliberately. A public fetcher that could reach localhost or 192.168.x.x would let anyone use this server to probe networks they cannot reach themselves. Deploy to a staging URL that is publicly reachable and check that instead.

Sixteen characters for ordinary accounts stored in a password manager. Twenty or more for anything protecting other credentials - your email, your password manager's master password, a cloud root account. Length matters more than complexity: sixteen lowercase letters beat ten mixed characters.

It is the size of the guess space, in bits, where each bit doubles the number of guesses needed. It is a better measure than counting character types because it accounts for length, which matters far more. Under 28 bits is trivial, 60 is reasonable, above 80 is strong.

No. Those are obfuscated precisely to defeat automatic extraction, and they are not valid addresses as written. The extractor matches real addresses only, which means it will miss deliberately disguised ones.

Because they are not complete addresses. /about and //example.com/page have no protocol, and without knowing which page they appeared on there is no way to resolve them into real URLs. Only absolute http and https links are matched.

No. The image is read by your browser and decoded on your own machine. Camera frames are processed the same way and never transmitted. The only network request is fetching the decoder library once, and no image data accompanies it.

Yes. Choose Custom in either dropdown and type whatever you need - a double pipe, a caret, an arrow, even a word like and. The text is matched exactly as you type it, including any spaces, so be deliberate about whether you want and or and .

Word processors disagree with each other about edge cases. Hyphenated compounds, numbers with separators, and text around em-dashes are all counted differently depending on the program. This tool splits on whitespace, which matches Word in most ordinary prose but can differ by one or two in text with unusual punctuation.

Because the splitter treats every capital as the start of a new word, and there is no dependable way to distinguish HTML from three consecutive one-letter words. parseHTMLDocument becomes parse_h_t_m_l_document. Acronym-heavy names need a manual fix afterwards.

Off for email addresses, URLs and general text, where Example@Site.com and example@site.com are the same address. On for file paths on Linux servers, variable names, API keys and product codes, where the capitals are part of the identifier.

To keep the output decodable. Without padding, 1234 could be two characters or four. Fixed widths - two digits for hex, eight for binary, three for decimal - remove the ambiguity, and the decoder depends on that convention when reading unseparated input.

Reverse it by characters and compare the two versions. If you want the relaxed definition, where A man, a plan, a canal: Panama qualifies, strip the spaces and punctuation and lowercase everything first - the Case Converter and Text Separator will do that in two steps.

No. Whitespace outside of string values carries no meaning in JSON, so two-space, four-space and tab indentation all parse to exactly the same structure. Only whitespace inside a quoted string is part of the data.

Whenever the encoded value will appear in a URL. Standard Base64 uses + and /, which a URL interprets as a space and a path separator. URL-safe mode swaps them for - and _. JSON Web Tokens and most modern APIs use this variant.

Whitespace between inline elements renders as a visible space, and collapsing it removes that space. It affects span, a, em and similar inline tags. Flexbox and grid layouts are unaffected because they ignore that whitespace already.

Shorthand only works when each pair of digits repeats. #aabbcc can be written #abc because every pair doubles. #1e93e8 has no repeating pairs, so shortening it would produce a different colour. Only exact conversions are made.

Technically yes, but check the licence first. Many open-source libraries require their licence header to remain in distributed files, and removing comments removes it. Most libraries also ship a pre-minified build, which is a better starting point anyway.

Yes, because the values come from the browser's cryptographic generator rather than Math.random(). A version 4 UUID from a secure source cannot be predicted from previously issued ones, which is exactly the property a reset link needs.

Usually, but read the result. Dropping the, of, and, to makes slugs shorter and no less clear most of the time. Occasionally the small word matters - removing not reverses the meaning, and the-office is a different thing from office.

Because it was encoded in full URL mode, which leaves ampersands alone. The outer URL then reads your redirect target's ampersand as the start of a new parameter. Encode redirect targets in component mode so their internal structure is escaped.

Because plus-as-space was on. In form-encoded data a plus means a space, so user+tag@example.com decodes to user tag@example.com. Turn the option off when the value contains a genuine plus - plus-addressed emails and international phone numbers being the usual cases.

They are almost certainly being added by JavaScript after the page loads. This reads the HTML the server returns, which is also what many crawlers see. Rather than a limitation to work around, treat it as a finding: tags that need JavaScript to exist are invisible to anything that does not run it.

It depends entirely on whether generation happens locally. Here it does - the browser's own cryptographic generator produces the value and nothing is transmitted. A generator that produced passwords on a server would be sending you a secret over the network, which is a different proposition.

Probably because it is short, or because it contains a recognisable word or pattern. Character variety widens the alphabet slightly; length multiplies the search space. Password1! ticks every box and is still among the first things any attacker tries.

Extracting from your own data is ordinary processing. Harvesting from public pages to send unsolicited email is prohibited by CAN-SPAM in the United States and lacks a lawful basis under GDPR. It also fails practically - harvested lists generate complaints that get sending domains blocklisted.

Type your domain into the domain filter. Only links whose hostname contains that text are kept. Run it once with the filter for the internal set, then compare against the unfiltered list to see the external ones.

Three usual causes. Browsers require HTTPS for camera access, so an insecure connection blocks it. Permission may have been denied - check the padlock in the address bar. Or another application is already using the camera. Uploading a photo works regardless.

No. The first occurrence of each item stays exactly where it was and later repeats are dropped. If you want the result sorted, use the Duplicate Line Remover instead, which has a sort option.

No, and it is worth understanding why. Google truncates titles based on pixel width, not character count, so a title full of narrow letters like i and l can run longer than one full of capitals and Ws. Sixty is a reliable working number, not a rule.

Yes. The five programming formats handle each line independently, so paste a column of names, pick your format, and convert them all in one go. The prose formats deliberately do not do this, because sentences often run across line breaks.

Almost always an invisible character. A trailing space, a tab, or a carriage return left over from a Windows file will make two lines differ without any visible sign. Turn on trim whitespace and run it again - that resolves it in most cases.

Paste the problem text, encode it to decimal with space separators, and read the numbers. 32 is a normal space; 160 is a non-breaking space, 9 is a tab, 13 is a carriage return and 8203 is a zero-width space. Any of those four will break a comparison while looking like nothing at all.

Composite emoji are made of several code points held together by invisible joining characters. Reversing them individually separates the parts and the joiners end up in the wrong place. Accented letters and CJK characters reverse correctly; multi-person and skin-tone emoji are the known exception.

Comparing documents. Objects have no defined key order, so two responses with identical data can serialise in different orders and produce a diff full of noise. Sort both alphabetically and the only differences left are the real ones.

Usually a character set mismatch. Base64 encodes bytes, so the text has to become bytes first, and if the encoder used something other than UTF-8 - Latin-1 on an older system, for instance - the bytes decode to the wrong characters. It can also mean the string was truncated in transit.

For size, marginally. For privacy, often yes. Comments regularly contain server names, ticket references, plugin versions and commented-out experiments. None of that belongs in a page the public can view source on.

No, and that is intentional. Detecting unused CSS requires analysing every page and every state your JavaScript can produce, and getting it wrong silently breaks things. This tool only removes characters, which is why you can run it without re-testing the whole site.

No. The scanner tracks whether it is inside a string, a template literal or a comment as it reads, so a URL like "https://example.com" survives intact. This is the single most common bug in simplistic minifiers.

Be careful with MySQL. InnoDB orders rows physically by primary key, and random UUIDs cause inserts to scatter through the index, fragmenting it as the table grows. Keep an auto-increment key internally and index the UUID separately, or use a time-ordered format such as UUID v7.

Only with a 301 redirect from the old address to the new one. Without it every existing link breaks, the accumulated ranking signals are lost, and anyone who bookmarked the page gets a 404. The redirect keeps most of that value, but the cleanest answer is to decide the slug once.

%20 is valid anywhere and is the safer default. A plus means a space only in form-encoded data, which is what an HTML form sends on a GET submission. In a path segment a plus is a literal plus, so never use it there.

Yes. Decoding is pure text manipulation performed in your browser - no request is made and the site in question never learns anything. Reading the decoded destination before clicking is a sensible habit, and a mismatch between the claimed sender and the real domain is a clear warning.

No. Google truncates by pixel width, so a title of narrow letters can run longer than one full of capitals. Sixty is a dependable working threshold rather than a rule, which is why it is flagged as a warning rather than an error.

Because l, I and 1 are hard to distinguish in many fonts, as are O, 0 and o. If the password will be read aloud, written on paper or typed from one screen onto another device, excluding them removes a real source of frustration. Add a character or two to make up for the smaller alphabet.

No, and no offline checker can. A password can be long and random-looking while sitting in a public wordlist from an old breach. Use a service that queries breach data with k-anonymity, such as Have I Been Pwned, which checks without ever receiving the full password.

Common causes: an unusual top-level domain longer than 24 characters, a space accidentally inside the address, a line break splitting it in two, or HTML entities in place of the @. Check the raw text around where you expected it.

Paste the page source and filter to HTTP only. Anything returned is an insecure resource being loaded from a secure page, which is what browsers block and what removes the padlock. It is the fastest way to find the leftovers after an HTTPS migration.

The code itself is only data, so decoding it here is safe. The risk is in where it leads. Stickers placed over legitimate codes on parking meters and restaurant tables are a well-established scam, usually leading to a convincing payment page. Read the destination before opening it.

It is. Blue and blue are treated as two different items here. If you need case-insensitive de-duplication, run the text through the Case Converter first to normalise it, then separate it.

No. It counts words at 225 per minute and nothing else. An article heavy with screenshots or code samples takes longer to work through than the estimate suggests, so treat it as a floor rather than a prediction.

Title Case follows editorial convention and leaves small joining words lowercase. Capitalise Each Word capitalises everything without exception. Use the first for headlines, the second for names, menu labels and table headers.

Paste both lists into the box one after the other, then tick show only duplicates. Any line appearing in both files will be repeated in the combined text and will surface in the output. The result is the overlap between the two.

Yes. The decoder splits on spaces, commas, semicolons, pipes and line breaks, and it tolerates a mixture of them. What it cannot do is guess the base, so make sure the dropdown matches how the codes were written before you convert.

Yes, and that is the main reason to use line reversal. Sorting a list descending discards your existing order and rebuilds it. Reversing the line order simply turns the list upside down, which is faster and keeps any ordering that sorting would have destroyed.

Files of a few megabytes are fine. Beyond roughly ten megabytes the browser may pause noticeably while parsing, because everything is held in memory at once. For files that large a command-line tool such as jq will be more comfortable.

Padding. Base64 works on groups of three bytes, and when the input does not divide evenly the output is padded to a multiple of four characters. URL-safe mode usually drops the padding, and the decoder here adds it back automatically when it is missing.

Typically 15% to 25% before gzip. Deeply nested, heavily indented markup saves most; already-compact pages save little. The counters show your actual figure. Remember that gzip on the server captures much of this saving anyway, so the incremental gain is smaller than the raw percentage suggests.

For browsers, entirely - the specification makes it optional. The risk is in tooling: some older preprocessors and CSS-in-JS parsers object. It is off by default for that reason, and the saving is one byte per rule.

No. JavaScript's automatic semicolon insertion has well-known edge cases where omitting one changes what the code does, and the byte saved is not worth that risk. Every semicolon you wrote stays.

Version 4 is purely random. Version 1 encodes a timestamp and the machine's MAC address, which leaks information. Versions 3 and 5 are hashes of a name, so the same input always yields the same output. Version 7 is time-ordered and increasingly popular for database keys. Version 4 is the right default when you just need a unique value.

They are stripped, because there is no meaningful ASCII transliteration. For those languages, write the slug yourself - either an English rendering of the topic or a short descriptive phrase - rather than generating it from the title.

Browsers will display them and often handle them for you, but they are percent-encoded the moment the link is copied or passed between systems. Encoding them yourself makes the behaviour predictable rather than dependent on which client touches the link.

The string contains a malformed percent sequence - a % not followed by two valid hex digits. That usually means the URL was truncated in transit, or a literal percent sign was included without being encoded. Check for a cut-off ending first.

Yes, and this is the one tool on the site that does. The address goes to our server, which makes the fetch, because browsers are not permitted to request arbitrary other websites. Every other utility here runs entirely on your own machine.

Current guidance from NIST says no - forced rotation makes people choose weaker, more predictable variations. Change a password when there is a reason: a breach notification, a shared credential, or a suspicion something is wrong. Otherwise a long unique password can stay as it is.

The checking happens entirely in your browser with no network request, so nothing is transmitted or stored. Even so, the safest habit anywhere is to test a variation of the same length and structure rather than the exact password you use.

Generally yes. Domains are case-insensitive and every mail provider in ordinary use treats the local part that way too. More usefully, lowercasing before de-duplication means Bob@Example.com and bob@example.com are recognised as one address rather than two.

No. It extracts what is present in the text without making any requests. Feed the resulting list into a dedicated link checker to test which ones respond - keeping the two steps separate is also what allows this one to run entirely in your browser.

Almost always image quality. Blur, a steep angle, glare on a printed surface, poor light or an image scaled down too far will all defeat it. QR codes tolerate physical damage well but not an unfocused photograph. Retry straight on, in better light.

There is no fixed limit because the work happens on your own machine. Tens of thousands of lines are fine on a normal computer. Very large pastes - a hundred thousand lines or more - may pause the browser for a second while it works, which is the browser being busy rather than an error.

No. The counting happens in your browser as you type and the text is never sent anywhere. Nothing is written to a server, nothing is logged, and closing the tab discards it. You can safely paste unpublished or confidential drafts.

The prose formats leave punctuation, numbers and symbols untouched and only change letters. The code formats are more aggressive by design: they strip punctuation entirely, because a variable name cannot contain a comma or a full stop.

After. Duplicates are found in the original order, so the first occurrence is genuinely the first one from your source. Sorting is then applied to the cleaned result, which means turning sorting on never changes which copy was kept.

Because two hex digits map exactly onto one byte, with no remainder. Every possible byte is 00 to FF - always two characters, never more or fewer. Decimal has no such tidy relationship with byte boundaries, which is why hex dumps, colour codes and memory addresses all use it.

In character mode, line breaks are characters like any other, so they move with everything else and the layout changes completely. In line mode, breaks define the units being reordered and the structure stays intact. Word mode preserves the whitespace it finds, including newlines.

No. It is parsed by your browser's own JSON engine, entirely on your machine. Nothing is transmitted or logged, which is deliberate - API responses routinely carry access tokens and personal data that should not be pasted into a third-party service.

Yes. A JWT is three URL-safe Base64 segments separated by dots. Paste the first for the header, the second for the payload, and both will decode to readable JSON. The third is a cryptographic signature and will not produce anything legible - that is expected.

Automate it if you have a build process - minifying by hand means your source and your published file drift apart. This tool is for the situations without one: CMS blocks, email templates, or a quick check of what a page could save.

Either works, but concatenate in the order the browser would have loaded them. CSS resolves ties by source order, so a reordered concatenation can change which rule wins - and the minifier usually gets blamed for the resulting visual change.

If you have a build pipeline and a test suite, use a proper minifier there - it will save far more. This is for the code that lives outside a pipeline: snippets, tag manager blocks and files uploaded by hand.

For comparison, no - UUIDs are case-insensitive. For storage, be consistent. A column holding a mixture will not match on a plain string comparison unless your collation is case-insensitive, which is a subtle bug to chase later.

Three to six meaningful words is the usual advice, which lands around 40 to 60 characters. The default cap here is 75, and slugs are trimmed at a word boundary rather than mid-word so the result still reads as language.

Yes, and it is a common bug. Encoding an already-encoded string turns every % into %25, so %20 becomes %2520. If you see %25 in a URL, something has been encoded one time too many. Decode it once and check before encoding again.

Yes. Paste only the value you care about. This is often clearer for large parameters such as an OAuth state or a base64 payload, where decoding the whole URL produces more output than you need.

Because the meta description is a suggestion, not an instruction. Google frequently substitutes a passage from the page body when it judges that a better match for the query. A well-written description is still worth having - it is used most of the time, and it is what social platforms fall back on.

Turn off the character class it objects to and generate again. Some sites still reject symbols or cap length at twelve characters. Both are poor practices on their part, but the workaround is to fit their rules and use the maximum length they allow.

A passphrase of four or five genuinely random words is both strong and memorable, which is why it is good advice for passwords you must type from memory. A quotation or a phrase you chose yourself is not random and scores far lower than its length suggests.

No. It matches the shape of an address, not its existence. nobody@example.com is a perfect match and delivers nowhere. Verifying deliverability requires querying mail servers, which is a different kind of tool entirely.

Trailing full stops, commas, semicolons and colons are trimmed automatically, but a closing bracket that is genuinely part of the URL - Wikipedia article titles are the classic case - is ambiguous. Check any link ending in a bracket by hand.

A QR code can hold any short text. Common non-link contents are Wi-Fi credentials, contact details in vCard format, calendar events, phone numbers and payment strings. The reader shows the raw text for all of these, so you can see exactly what a code would have handed to your phone.

TU Web Tools is a free online platform offering powerful web-based utilities for developers, SEO professionals, marketers, students, businesses, and everyday internet users. Our tools help simplify common digital tasks without requiring software installation.

Yes. All tools on TU Web Tools are available free of charge. You can use them anytime without purchasing subscriptions or software.

No. Most of our tools work instantly without registration or login.

Absolutely. All tools are fully responsive and work on smartphones, tablets, laptops, and desktop computers.

No. You can use our online tools as often as you need.

No. Most of our tools process your data instantly in your browser or temporarily on our servers without permanently storing your information.

Yes. Passwords entered into our Password Generator and Password Strength Checker are not permanently stored or shared.

No. Files uploaded to supported tools are processed temporarily and are not permanently stored.

Yes. We use HTTPS encryption and follow industry best practices to provide a secure browsing experience.

TU Web Tools currently provides:

• Text Tools
• Developer Tools
• SEO Tools
• Utility Tools

More tools are added regularly.

Our tools work with all modern browsers, including:

• Google Chrome
• Microsoft Edge
• Mozilla Firefox
• Safari
• Opera

No. Everything runs directly inside your web browser.

Yes. You may use our tools for personal, educational, and commercial projects.

Our tools are designed to provide fast and reliable results. However, users should always verify important information before relying on it for critical decisions.

We continuously improve TU Web Tools by adding new online utilities and updating existing ones.

Visit our Contact Us page and send us your suggestion. We welcome ideas from our users.

Yes. If you discover an issue, please contact our support team with detailed information so we can investigate.

You can reach us through our Contact Us page or email us directly at:

support@tuwebtools.com

Yes. Our SEO tools help analyze websites, optimize URLs, generate slugs, check meta tags, and perform other SEO-related tasks.

Absolutely. We offer several developer-focused utilities including:

• JSON Formatter
• Base64 Encoder
• HTML Minifier
• CSS Minifier
• JavaScript Minifier
• UUID Generator

Yes. Most text-based tools support Unicode, making them suitable for multiple languages.

Yes. Businesses frequently use our tools for productivity, website management, marketing, content creation, and development tasks.

At this time, TU Web Tools focuses on providing free public online utilities. We may consider custom solutions in the future.

Possible reasons include:

• Unsupported browser
• Temporary internet issues
• Browser extensions interfering
• Cached browser data

Refreshing the page or trying another browser often resolves the issue.

Different tools may use different processing methods or standards. Always review important results before use.

Use our:

• HTML Minifier
• CSS Minifier
• JavaScript Minifier

to reduce file sizes and improve loading speed.