Forem: Mathabo Motaung

Decoding Base64 With PowerShell

Mathabo Motaung — Wed, 07 Jan 2026 00:35:04 +0000

Using Windows PowerShell to decode base64

Developers often encounter Base64 strings. You might see them in configuration files or API responses. They represent binary data in a text format.

Comparison

Linux users decode these strings easily. They use the terminal command base64 with the decode flag. It is quick and native.

Windows users often struggle with this task. PowerShell does not have a direct equivalent to the Linux command. You might try to find a specific cmdlet. You will not find one.

Fact

PowerShell relies on the .NET framework. This is a strength. It gives you access to powerful system libraries. You can use these libraries to manipulate data.

Knowledge

Here is the logic. Base64 is a string. You must convert this string into a byte array. Then you convert that byte array into readable text.

Follow these steps to decode a string:

Step 1: Define your Base64 string. Assign it to a variable.

Step 2: Convert the string to bytes. Use the System.Convert class. It has a static method called FromBase64String.

$Bytes = [System.Convert]::FromBase64String($EncodedString)

Step 3: Decode the bytes. Use the System.Text.Encoding class. The UTF8 property works for most modern text. Use the GetString method on the byte array.

The output will be the decoded text. In this example, it is Hello World.

Summary

This method is reliable. It works on all modern versions of PowerShell. It does not require external tools. It scripts well for automation tasks.

Understanding the underlying types helps you. You are not just running a black box command. You are manipulating data types directly. This is the PowerShell way.

Debugging PowerShell vs. Bash for Local API Testing

Mathabo Motaung — Tue, 06 Jan 2026 12:15:46 +0000

Why your curl commands fail on Windows, and how to fix them without installing WSL.

If you are a Java developer moving between Linux servers and a local Windows environment, you have probably hit this wall. You copy a perfectly valid curl command from a tutorial or documentation, paste it into your PowerShell terminal, and get a wall of red text.

I ran into this while testing S3entinel, my Spring Boot file ingestion service. I wanted to manually test my new Controller endpoint, but my terminal refused to cooperate.

The Setup

I had just deployed a FileController in Spring Boot that accepts multipart/form-data uploads.

@PostMapping("/upload")
public ResponseEntity<String> uploadFile(@RequestParam("file") MultipartFile file) {
    // ... logic to handle file bytes
    return ResponseEntity.accepted().body("File accepted for processing.");
}

To test it quickly without opening Postman, I ran this standard command:

curl -X POST -F "file=@wb.jpg" http://localhost:8080/api/v1/files/upload

The Error

Instead of a 202 Accepted response, PowerShell threw an exception I didn't expect:

Invoke-WebRequest : A parameter cannot be found that matches parameter name 'X'.
At line:1 char:6
+ curl -X POST -F "file=@wb.jpg" ...
+      ~~
    + CategoryInfo          : InvalidArgument: (:) [Invoke-WebRequest], ParameterBindingException
    + FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

The "Aha!" Moment

The error message Invoke-WebRequest gives it away.

In PowerShell, curl is not the actual cURL binary we know and love from Linux. It is an Alias for a native Windows cmdlet called Invoke-WebRequest.

While Invoke-WebRequest is powerful, it does not share the same syntax flags as standard cURL:

It doesn't use -X for methods (it uses -Method).
It doesn't use -F for form data (it uses -Form).

So, when I typed curl -X, PowerShell thought I was passing a parameter named -X to Invoke-WebRequest, which doesn't exist.

The Fix: Be Explicit

You don't need to rewrite your command into PowerShell syntax (which is verbose). You just need to tell PowerShell to ignore its alias and use the actual executable installed on your system.

By appending .exe, you bypass the alias lookup and run the program directly.

The Working Command

curl.exe -v -X POST -F "file=@wb.jpg" http://localhost:8080/api/v1/files/upload

Why this works:

curl: PowerShell sees an alias for Invoke-WebRequest.

curl.exe: PowerShell looks for an executable file in your System PATH. Since Git Bash or Windows System32 usually installs the real cURL, it finds the Linux-compatible tool.

Summary

When working in hybrid environments (Windows Local + Linux Cloud), "simple" commands often break due to shell differences.

If you see Invoke-WebRequest errors when you meant to run curl, remember: When in doubt, add .exe.

Code Reference:

How to Fix CloudFormation Circular Dependencies in AWS SAM

Mathabo Motaung — Tue, 06 Jan 2026 00:03:13 +0000

The "Chicken and Egg" problem when connecting S3 Buckets to Lambda Triggers.

If you have ever tried to build an Event-Driven architecture with AWS SAM, you have likely seen this error message. It usually appears 5 minutes into a deployment, just when you think everything is working:

Error: Failed to create changeset for the stack: s3entinel-stack Status: FAILED. Reason: Circular dependency between resources: [ImageProcessorFunctionRole, ImageProcessorFunction, S3entinelBucket, ImageProcessorFunctionFileUploadPermission]

I hit this wall while building S3entinel, a Spring Boot + Serverless hybrid application. Here is exactly why this happens and the simple Sub-trick I used to fix it.

The Architecture

The goal was simple:

S3 Bucket (S3entinelBucket) receives a file.
Lambda Function (ImageProcessorFunction) gets triggered automatically.
Lambda reads the file metadata and logs it.

To make this work, two things must happen in the infrastructure:

The Bucket needs to know the Lambda's ARN to send the notification.
The Lambda needs permission (IAM Policy) to read from The Bucket.

The Problem: Chicken vs. Egg

In CloudFormation (the engine underneath SAM), resources are created in a specific dependency order.

To create the Bucket Notification, AWS needs the Lambda Function to exist first.
To create the Lambda Function, AWS needs to create its IAM Role.
If you reference the Bucket inside that IAM Role (to give it Read permissions), the Role now waits for the Bucket.

The Cycle:

Bucket waits for Lambda → Lambda waits for Role → Role waits for Bucket.

The "Bad" Code (What Causes the Loop)

Here is the intuitive (but wrong) way to write the template.yaml. Notice how I tried to rely on !Ref S3entinelBucket inside the function's policy.

In YAML file:

Resources:
  S3entinelBucket:
    Type: AWS::S3::Bucket

  ImageProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Handler: com.codebymathabo.s3entinel.lambda.ImageProcessor::handleRequest
      Events:
        FileUpload:
          Type: S3
          Properties:
            Bucket: !Ref S3entinelBucket # Lambda needs Bucket for Event
            Events: s3:ObjectCreated:*
      Policies:
        - S3ReadPolicy:
            BucketName: !Ref S3entinelBucket # Role needs Bucket for Permissions

This creates the deadlock. CloudFormation cannot resolve the dependency graph.

The Fix: Break the Chain with Strings

To solve this, we must remove one of the hard dependencies. We can’t change the Event trigger (that requires a real resource reference), but we can cheat on the IAM Policy.

Instead of asking CloudFormation to "Wait for the Bucket to exist and then give me its name" (!Ref), we can construct the bucket name manually using a deterministic naming pattern.

In AWS, if you know the Region and Account ID, you can predict the bucket name before it is even created.

The "Good" Code
Here is the fix I implemented in S3entinel. I replaced the !Ref in the Policy section with a !Sub string interpolation.

In YAML file:

Resources:
  # Define the Bucket Name explicitly using ID and Region
  S3entinelBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub 's3entinel-iac-${AWS::Region}-${AWS::AccountId}'

  ImageProcessorFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Handler: com.codebymathabo.s3entinel.lambda.ImageProcessor::handleRequest

      # Reconstruct the name string manually.
      # This grants permission to "what the bucket WILL be named"
      # without forcing the IAM Role to wait for the Bucket resource.
      Policies:
        - S3ReadPolicy:
            BucketName: !Sub 's3entinel-iac-${AWS::Region}-${AWS::AccountId}'

      Events:
        FileUpload:
          Type: S3
          Properties:
           # Keep the hard link for the trigger
            Bucket: !Ref S3entinelBucket 
            Events: s3:ObjectCreated:*

Why This Works

By using !Sub 's3entinel-iac-${AWS::Region}-${AWS::AccountId}', we are giving the IAM Role a string of text, not a resource dependency.

CloudFormation creates the IAM Role immediately (it only needs the string, not the bucket).
It creates the Lambda Function using that Role.
Finally, it creates the S3 Bucket (which depends on the Lambda for the notification trigger).

The loop is broken, the stack deploys, and the Circular Dependency error disappears.

Code Reference: