{"id":1256615,"date":"2026-06-19T03:02:58","date_gmt":"2026-06-19T07:02:58","guid":{"rendered":"https:\/\/www.ituonline.com\/tech-definitions\/powershell-foreach-and-foreach-object-when-to-use-each\/"},"modified":"2026-06-19T03:03:09","modified_gmt":"2026-06-19T07:03:09","slug":"powershell-foreach-and-foreach-object-when-to-use-each","status":"publish","type":"post","link":"https:\/\/www.ituonline.com\/blogs\/powershell-foreach-and-foreach-object-when-to-use-each\/","title":{"rendered":"PowerShell Foreach and Foreach-Object: When to Use Each"},"content":{"rendered":"<p><strong>PowerShell<\/strong> gives you two ways to loop through data, and the choice matters more than most scripts make it look. If you are deciding between <strong>PowerShell foreach-object<\/strong> and the <strong>foreach<\/strong> language keyword, the real question is whether your <strong>PowerShell commands<\/strong> are working with an in-memory collection or a live pipeline stream. The wrong choice can hurt readability, memory use, and even performance in larger <strong>scripting<\/strong> jobs.<\/p>\n\n<div class=\"itu-tldr\" data-speakable=\"true\">\n  <p><strong>Quick Answer<\/strong><\/p>\n  <p>Use <strong>foreach<\/strong> when your data is already in memory and you want the fastest, clearest loop over a collection. Use <strong>ForEach-Object<\/strong> when you are processing pipeline output one object at a time, especially for streaming data or chained automation. In most PowerShell scripting, the deciding factors are speed, memory, pipeline compatibility, and readability.<\/p>\n<\/div>\n\n<table class=\"itu-at-a-glance\" data-speakable=\"true\">\n  <tbody>\n    <tr><th scope=\"row\">Primary form<\/th><td><strong>foreach<\/strong> keyword vs <strong>ForEach-Object<\/strong> cmdlet<\/td><\/tr>\n    <tr><th scope=\"row\">Best data source<\/th><td>Array, list, or variable already loaded<\/td><\/tr>\n    <tr><th scope=\"row\">Best data flow<\/th><td>Pipeline output from commands<\/td><\/tr>\n    <tr><th scope=\"row\">Memory behavior<\/th><td>Requires collection to be available first<\/td><\/tr>\n    <tr><th scope=\"row\">Streaming support<\/th><td>Processes objects as they arrive<\/td><\/tr>\n    <tr><th scope=\"row\">Typical use case<\/th><td>Logic-heavy loops and object construction<\/td><\/tr>\n    <tr><th scope=\"row\">Typical strength<\/th><td>Clearer syntax and often faster iteration<\/td><\/tr>\n    <tr><th scope=\"row\">Typical limitation<\/th><td>Not pipeline-native<\/td><\/tr>\n  <\/tbody>\n<\/table>\n\n<div>\n<table class=\"itu-comparison\" data-speakable=\"true\">\n  <thead><tr><th>Criterion<\/th><th>foreach<\/th><th>ForEach-Object<\/th><\/tr><\/thead>\n  <tbody>\n    <tr><th scope=\"row\">Cost (as of June 2026)<\/th><td>Included in PowerShell; no extra cost<\/td><td>Included in PowerShell; no extra cost<\/td><\/tr>\n    <tr><th scope=\"row\">Best for<\/th><td>In-memory collections and explicit loops<\/td><td>Pipeline input and streamed processing<\/td><\/tr>\n    <tr><th scope=\"row\">Key strength<\/th><td>Speed, readability, direct control<\/td><td>Pipeline compatibility and lower memory pressure<\/td><\/tr>\n    <tr><th scope=\"row\">Main limitation<\/th><td>Must usually have the full collection first<\/td><td>More overhead and less natural for complex loop logic<\/td><\/tr>\n    <tr><th scope=\"row\"><strong>Verdict<\/strong><\/th><td><strong>Pick when you already have the data loaded and want a clean loop.<\/strong><\/td><td><strong>Pick when the next command feeds the current one.<\/strong><\/td><\/tr>\n  <\/tbody>\n<\/table>\n<\/div>\n\n<h2>Understanding the Two Approaches<\/h2>\n\n<p><strong>foreach<\/strong> is a language keyword that walks through a collection one item at a time after the collection is already available. <strong>ForEach-Object<\/strong> is a pipeline cmdlet that receives objects as they flow through PowerShell, which makes it a natural fit for streaming <a href=\"https:\/\/www.ituonline.com\/it-glossary\/?letter=S&amp;pagenum=1#term-scripting\">scripting<\/a> patterns and chained <strong>PowerShell commands<\/strong>.<\/p>\n\n<p>The difference is not cosmetic. One is a statement-based loop, and the other is a pipeline-based command. Both can do similar work, but they behave differently in how they acquire input, when they begin processing, and how much memory they need to hold onto data.<\/p>\n\n<blockquote>\n  <p><strong>Pipeline-friendly code is not automatically better code.<\/strong> In PowerShell, the right loop is the one that matches the shape of the data and the intent of the script.<\/p>\n<\/blockquote>\n\n<h3>Statement-based iteration versus pipeline-based processing<\/h3>\n\n<p>With <strong>foreach<\/strong>, PowerShell first evaluates the collection and then iterates across it. That makes it ideal when the whole dataset is already in a variable, such as an array of service names, a list of files, or query results you stored earlier in the script. The loop body is explicit and easy to trace.<\/p>\n\n<p><strong>ForEach-Object<\/strong> works differently. It consumes objects from the pipeline as they arrive, so it does not need the whole set loaded before processing starts. That makes it useful for streams, especially when the source command may return a very large number of objects or when you want to chain filtering, transformation, and output in one pipeline.<\/p>\n\n<p>The practical takeaway is simple: <strong>foreach<\/strong> is usually the better fit for collection-first logic, while <strong>ForEach-Object<\/strong> is better for pipeline-first automation. They are not interchangeable in the way they handle data flow, and that difference drives most of the decision.<\/p>\n\n<h2>How Foreach Works in PowerShell<\/h2>\n\n<p>The basic syntax is <strong>foreach ($item in $collection)<\/strong>. In that statement, <strong>$item<\/strong> is the current object being processed, <strong>in<\/strong> is the iterator keyword, and <strong>$collection<\/strong> is the array or list you want to walk through. The loop body runs once for each item in the collection.<\/p>\n\n<p>Because the collection is usually evaluated before the loop starts, <strong>foreach<\/strong> often expects all data to be available up front. That means the script may allocate memory for the full collection first, then begin iteration. For small and moderate datasets, that is usually fine. For very large datasets, the memory cost can matter.<\/p>\n\n<p>Here is the kind of pattern that fits <strong>foreach<\/strong> well:<\/p>\n\n<pre><code class=\"\" data-line=\"\">$services = @(&#039;Spooler&#039;, &#039;wuauserv&#039;, &#039;BITS&#039;)\nforeach ($service in $services) {\n    Write-Host &quot;Checking $service&quot;\n}<\/code><\/pre>\n\n<h3>Common use cases for foreach<\/h3>\n\n<p><strong>foreach<\/strong> works especially well when you already have a variable containing the data you need. That includes arrays, file lists built earlier with <code class=\"\" data-line=\"\">Get-ChildItem<\/code>, and query results held in memory after a database fetch or API call. You can also use it to build custom objects, enrich data, or apply logic that depends on previous items or the whole set.<\/p>\n\n<ul>\n  <li><strong>Arrays:<\/strong> Iterate over a fixed list of names, paths, or values.<\/li>\n  <li><strong>File collections:<\/strong> Loop through files stored in a variable and rename, copy, or inspect them.<\/li>\n  <li><strong>Stored results:<\/strong> Process command output after collecting it once.<\/li>\n  <li><strong>Object construction:<\/strong> Create new objects from the data you already have.<\/li>\n<\/ul>\n\n<p>The readability advantage is real. Many admins find <strong>foreach<\/strong> easier to debug because the structure is obvious, the variables are explicit, and the loop logic looks like a normal statement rather than a pipeline transformation. If the script is primarily about <strong>iteration<\/strong> and business logic, this clarity helps.<\/p>\n\n<h2>How ForEach-Object Works in PowerShell<\/h2>\n\n<p><strong>ForEach-Object<\/strong> is a pipeline cmdlet that is usually written as <code class=\"\" data-line=\"\">Get-Process | ForEach-Object { ... }<\/code>. Each incoming object is processed in sequence, and the cmdlet does not require the full result set to be stored before it begins. That is why it is a natural fit for streaming output from <strong>PowerShell commands<\/strong>.<\/p>\n\n<p>Inside the script block, <strong>$_<\/strong> and <strong>$PSItem<\/strong> both refer to the current object. In practice, they are interchangeable in most scenarios, though many scripters prefer <strong>$PSItem<\/strong> for readability because it is a little more descriptive. The important point is that you are working with the current pipeline item, not a separate loop variable declared in advance.<\/p>\n\n<pre><code class=\"\" data-line=\"\">Get-Process | ForEach-Object {\n    &quot;$($_.ProcessName) - $($_.Id)&quot;\n}<\/code><\/pre>\n\n<h3>Begin, Process, and End blocks<\/h3>\n\n<p><strong>Begin<\/strong>, <strong>Process<\/strong>, and <strong>End<\/strong> blocks give <strong>ForEach-Object<\/strong> more control. <strong>Begin<\/strong> runs once before the first pipeline item arrives, <strong>Process<\/strong> runs once per object, and <strong>End<\/strong> runs once after the stream finishes. That structure is useful when you need setup, per-item actions, and cleanup in a single command.<\/p>\n\n<ol>\n  <li><strong>Begin:<\/strong> Initialize counters, arrays, or helper values.<\/li>\n  <li><strong>Process:<\/strong> Handle each incoming object from the pipeline.<\/li>\n  <li><strong>End:<\/strong> Output a summary, flush results, or close resources.<\/li>\n<\/ol>\n\n<p>This model fits PowerShell\u2019s design philosophy: commands produce objects, the pipeline passes them along, and each stage can transform or consume them. If your workflow is already pipeline-driven, <strong>ForEach-Object<\/strong> feels natural rather than forced.<\/p>\n\n<div class=\"itu-callout itu-callout--info\"><p><strong>Note<\/strong><\/p><p><strong>ForEach-Object<\/strong> is not just a loop with a different name. It is a command in the pipeline, and that changes how it handles input, memory, and flow control.<\/p><\/div>\n\n<h2>When Foreach Is the Better Choice<\/h2>\n\n<p>Use <strong>foreach<\/strong> when you already have the data loaded in memory and want the simplest, most readable syntax. In many looping scenarios, it is also faster because it avoids the overhead of repeated pipeline processing. That matters when the loop is doing straightforward work over a large collection of objects.<\/p>\n\n<p>It is also the better choice when you need easier debugging. A statement-based loop is more familiar to many scripters, and it is easier to set breakpoints, inspect variables, and reason about what happens on each pass. If the code is dense enough already, the last thing you want is to hide the iteration inside a pipeline.<\/p>\n\n<h3>Best-fit scenarios for foreach<\/h3>\n\n<ul>\n  <li><strong>Arrays and lists:<\/strong> You loaded the data first, then want to process it.<\/li>\n  <li><strong>Random access needs:<\/strong> You care about indexing or reference to the full dataset.<\/li>\n  <li><strong>Logic-heavy loops:<\/strong> The loop has multiple branches, nested conditions, or object creation.<\/li>\n  <li><strong>Custom object building:<\/strong> You want to assemble output records from existing values.<\/li>\n<\/ul>\n\n<p>For example, if you pull file names into a variable and then sort, group, or transform them, <strong>foreach<\/strong> keeps the logic clean. The same is true for query results stored in a collection, where you may need to inspect the entire set before deciding what to do next. In those cases, the loop is part of <strong>automation techniques<\/strong>, but it is not pipeline-dependent.<\/p>\n\n<p>One practical point: because <strong>foreach<\/strong> works with a collection already in hand, it often makes scripts easier to maintain. Future readers can immediately see the input, the loop, and the output without mentally reconstructing a pipeline chain.<\/p>\n\n<h2>When ForEach-Object Is the Better Choice<\/h2>\n\n<p>Use <strong>ForEach-Object<\/strong> when the source data comes from a cmdlet or command in the pipeline. That is the most idiomatic PowerShell pattern for transforming command output without first storing everything in a variable. It is especially useful when the result set may be large or unbounded.<\/p>\n\n<p>That memory behavior is the main advantage. Instead of materializing a full collection before the loop begins, <strong>ForEach-Object<\/strong> can process each item one at a time. For streaming tasks, log parsing, service inspection, or event handling, that can reduce memory pressure and keep the script responsive.<\/p>\n\n<h3>Common pipeline workflows<\/h3>\n\n<ul>\n  <li><strong>Get-ChildItem:<\/strong> Filter, rename, or inspect files as they flow through the pipeline.<\/li>\n  <li><strong>Get-Service:<\/strong> Transform service objects into status reports.<\/li>\n  <li><strong>Get-EventLog:<\/strong> Process events one at a time for reporting or alerting.<\/li>\n  <li><strong>Object transformation:<\/strong> Shape command output into a different object structure.<\/li>\n<\/ul>\n\n<p><strong>ForEach-Object<\/strong> also supports advanced pipeline patterns such as filtering and formatting. That makes it a strong fit when you are building composable workflows where each command has a clear job. If the script reads like a data stream, this cmdlet usually belongs in it.<\/p>\n\n<p>There is a performance tradeoff, though. The pipeline has overhead, so the most convenient option is not always the fastest one. If the script is not truly stream-oriented, the pipeline can add complexity without enough benefit.<\/p>\n\n<p>The <a href=\"https:\/\/learn.microsoft.com\/powershell\/\" target=\"_blank\" rel=\"noopener\">Microsoft Learn PowerShell documentation<\/a> is the best authoritative reference for command behavior, pipeline processing, and language syntax. It is also where you should verify how the current PowerShell version handles script blocks and pipeline input.<\/p>\n\n<h2>Performance, Memory, and Pipeline Considerations<\/h2>\n\n<p>On raw iteration speed, <strong>foreach<\/strong> usually wins in many looping scenarios because it avoids the extra overhead of the pipeline. For small tasks the difference may be negligible, but in larger data sets the direct loop often performs better. That is one reason experienced scripters reach for it when the data is already in memory.<\/p>\n\n<p><strong>ForEach-Object<\/strong> can reduce memory pressure because it avoids forcing the whole collection into a variable before processing starts. That benefit becomes important when working with large output from file enumeration, logs, or system inventory commands. It is a practical example of how <strong>streaming<\/strong> changes the design of a script.<\/p>\n\n<blockquote>\n  <p><strong>Optimize the data flow before you optimize the loop.<\/strong> In PowerShell, the biggest wins usually come from choosing the right pipeline shape, not from shaving milliseconds off a tiny loop.<\/p>\n<\/blockquote>\n\n<table>\n  <tbody>\n    <tr>\n      <th scope=\"row\"><strong>foreach<\/strong><\/th>\n      <td>Usually faster for direct iteration over an in-memory collection<\/td>\n    <\/tr>\n    <tr>\n      <th scope=\"row\"><strong>ForEach-Object<\/strong><\/th>\n      <td>Usually more memory-efficient for pipeline-fed, streamed objects<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Actual results depend on dataset size, object complexity, and surrounding commands. A script that does heavy formatting, sorting, or remote calls may spend more time outside the loop than inside it. That is why premature optimization is a trap. Choose the construct that matches the data source first, then measure if performance is still a problem.<\/p>\n\n<p>For workload context, the U.S. Bureau of Labor Statistics notes that the job market for systems and network administration remains substantial, with many routine tasks now automated through scripts and orchestration tools; see the <a href=\"https:\/\/www.bls.gov\/ooh\/\" target=\"_blank\" rel=\"noopener\">BLS Occupational Outlook Handbook<\/a>. For repeatable automation work, the loop you choose directly affects how cleanly a script scales from a one-off task to a production job.<\/p>\n\n<h2>Common Mistakes and Pitfalls<\/h2>\n\n<p>The biggest mistake is confusing <strong>foreach<\/strong> with <strong>ForEach-Object<\/strong> because the names look almost the same. They are not the same thing. One is a language keyword, the other is a cmdlet, and that distinction changes how they behave in a script.<\/p>\n\n<p>A second mistake is using <strong>ForEach-Object<\/strong> when a direct loop would be much clearer. Pipeline-heavy code can become harder to debug, especially when the script is doing more than simple transformation. If the logic is already complicated, hiding it in a long pipeline usually makes maintenance worse.<\/p>\n\n<h3>Scope and performance traps<\/h3>\n\n<ul>\n  <li><strong>Misreading $_:<\/strong> Inside <strong>ForEach-Object<\/strong>, <strong>$_<\/strong> refers to the current pipeline object, not a global loop variable.<\/li>\n  <li><strong>Repeated piping:<\/strong> Chaining small collections through the pipeline over and over adds unnecessary overhead.<\/li>\n  <li><strong>Delayed collection assumptions:<\/strong> <strong>foreach<\/strong> does not naturally stream without first having the data available.<\/li>\n  <li><strong>Variable scope confusion:<\/strong> Assigning inside the loop does not always behave the way a new scripter expects.<\/li>\n<\/ul>\n\n<p>Another common pitfall is forcing every task into pipeline style because it feels more \u201cPowerShell-like.\u201d That habit can create accidental performance problems. Sometimes the cleanest automation technique is to gather data first, then use <strong>foreach<\/strong> in a plain, readable loop.<\/p>\n\n<p>For scripting standards and secure automation habits, the <a href=\"https:\/\/csrc.nist.gov\/\" target=\"_blank\" rel=\"noopener\">NIST Computer Security Resource Center<\/a> is a useful reference for secure coding and control guidance. It is especially relevant when your PowerShell scripts are part of operational security, system hardening, or compliance workflows.<\/p>\n\n<h2>Practical Decision Guide<\/h2>\n\n<p>The simplest rule of thumb is this: use <strong>foreach<\/strong> for in-memory collections, and use <strong>ForEach-Object<\/strong> for pipeline input. That one decision eliminates most confusion and aligns the loop with the data source instead of with personal preference.<\/p>\n\n<p>When you need to decide quickly, look at four factors: where the data comes from, how large it is, whether the script benefits from pipeline chaining, and how much clarity the next person needs when they read the code. Those are the practical details that usually flip the recommendation.<\/p>\n\n<h3>Decision checklist<\/h3>\n\n<ol>\n  <li><strong>Is the data already in a variable?<\/strong> If yes, start with <strong>foreach<\/strong>.<\/li>\n  <li><strong>Is the data coming directly from a cmdlet?<\/strong> If yes, start with <strong>ForEach-Object<\/strong>.<\/li>\n  <li><strong>Do you need to process one item at a time without loading everything?<\/strong> Prefer <strong>ForEach-Object<\/strong>.<\/li>\n  <li><strong>Does the loop contain complex branching or indexing logic?<\/strong> Prefer <strong>foreach<\/strong>.<\/li>\n  <li><strong>Is the script mainly a chain of command transformations?<\/strong> Prefer <strong>ForEach-Object<\/strong>.<\/li>\n<\/ol>\n\n<p>Hybrid scripts are common and perfectly valid. A typical pattern is to use a cmdlet to gather or filter data, store the result if needed, and then apply <strong>foreach<\/strong> for the logic-heavy part. That gives you the best of both approaches without forcing the whole script into one style.<\/p>\n\n<p>For training and workforce context, the U.S. Department of Labor and NICE\/NIST Workforce Framework both emphasize practical, task-based skills in automation and system administration. The <a href=\"https:\/\/www.dol.gov\/\" target=\"_blank\" rel=\"noopener\">U.S. Department of Labor<\/a> and <a href=\"https:\/\/www.nist.gov\/itl\/applied-cybersecurity\/nice\" target=\"_blank\" rel=\"noopener\">NICE Framework<\/a> are worth reviewing if you want to align your scripting skills with job-role expectations.<\/p>\n\n<div class=\"itu-callout itu-callout--warning\"><p><strong>Warning<\/strong><\/p><p>Do not choose <strong>ForEach-Object<\/strong> just because you are piping data. If the data is already collected and the logic is simple, <strong>foreach<\/strong> is often easier to read, easier to debug, and faster.<\/p><\/div>\n\n<h2>When Should You Use foreach vs ForEach-Object?<\/h2>\n\n<p><strong>Use foreach when your data is already loaded, and use ForEach-Object when the pipeline is the source of truth.<\/strong> That is the short answer, and it covers most real-world PowerShell scripting decisions. If you remember only one thing, remember that the data flow should drive the loop choice.<\/p>\n\n<p>For example, use <strong>foreach<\/strong> when you have an array of server names and need to build a report, create objects, or apply multiple decision branches. Use <strong>ForEach-Object<\/strong> when you are reading from <code class=\"\" data-line=\"\">Get-ChildItem<\/code>, <code class=\"\" data-line=\"\">Get-Service<\/code>, or another command that already returns objects in sequence. That is the cleanest way to keep the script aligned with PowerShell\u2019s object pipeline model.<\/p>\n\n<p>The <a href=\"https:\/\/www.powershellgallery.com\/\" target=\"_blank\" rel=\"noopener\">PowerShell ecosystem<\/a> is built around object-based automation, but the loop itself should still match the task. A well-written script is not the one with the most pipeline commands. It is the one that makes the intent obvious and handles data efficiently.<\/p>\n\n<div class=\"itu-callout itu-callout--key\">\n  <p><strong>Key Takeaway<\/strong><\/p>\n  <p><strong>foreach<\/strong> is best for in-memory collections, direct iteration, and logic-heavy scripts.<\/p>\n  <p><strong>ForEach-Object<\/strong> is best for pipeline input, streaming data, and composable command chains.<\/p>\n  <p><strong>foreach<\/strong> is often faster for simple loops, while <strong>ForEach-Object<\/strong> is often more memory-efficient for large streams.<\/p>\n  <p>The best choice is the one that matches your data source, your readability goals, and your automation workflow.<\/p>\n<\/div>\n\n<h2>Conclusion<\/h2>\n\n<p>The core distinction is simple: <strong>foreach<\/strong> performs direct iteration over a collection, while <strong>ForEach-Object<\/strong> processes objects through the pipeline as they arrive. That difference affects speed, memory use, and how readable the script will be for the next person who has to maintain it.<\/p>\n\n<p>Pick <strong>foreach<\/strong> when you already have the data in memory and need the clearest possible loop. Pick <strong>ForEach-Object<\/strong> when your script is built around pipeline output and you want streaming behavior with strong composability. In both cases, the goal is the same: write PowerShell that is easy to understand, easy to maintain, and appropriate for the data you are handling.<\/p>\n\n<p>Pick <strong>foreach<\/strong> when the collection is already loaded and the loop logic is direct; pick <strong>ForEach-Object<\/strong> when the input is coming from the pipeline and you want streaming automation. If you want more practical PowerShell guidance like this, ITU Online IT Training focuses on the kind of scripting decisions administrators actually make on the job.<\/p>\n\n<p><em>Microsoft&reg; and PowerShell are trademarks of Microsoft Corporation.<\/em><\/p>","protected":false},"excerpt":{"rendered":"<p>Discover the key differences between PowerShell foreach and foreach-object to optimize your scripts, improve performance, and enhance readability in your automation tasks.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[333],"tags":[],"itu_content_category":[979,928,922],"class_list":["post-1256615","post","type-post","status-publish","format-standard","hentry","category-blogs","itu_content_category-command-references-cheat-sheets","itu_content_category-scripting-automation","itu_content_category-windows-server-administration"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/posts\/1256615","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/comments?post=1256615"}],"version-history":[{"count":1,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/posts\/1256615\/revisions"}],"predecessor-version":[{"id":1256618,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/posts\/1256615\/revisions\/1256618"}],"wp:attachment":[{"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/media?parent=1256615"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/categories?post=1256615"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/tags?post=1256615"},{"taxonomy":"itu_content_category","embeddable":true,"href":"https:\/\/www.ituonline.com\/wp-json\/wp\/v2\/itu_content_category?post=1256615"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}